suehares / fsv2-revision Goto Github PK

3.2.5 is actually a vpn redirect rather than the redirect-to-ip feature

General discussion point: For the various actions, do we really want to do the full zoo in one document? Minimally, it creates a conformance nightmare for partial support. From a document development standpoint, we want to consider how all of these things play together, but I think we'll still want the functionality split into different RFCs.

bgpsec isn't applicable to non-ipv4/ipv6 routing

roas on what? I think the intent here is to say "you can use this on the dst and then decide if the sending AS has authorization to do something on it". In principle, this isn't necessary if the underlying validation routes in the unicast RIB are themselves roa validated.

4.1

We talk about nexthop resolvability when we're throwing out the nexthop in the update.

The "validation" is likely mean to be the customer route validation procedures. The text should stick to more of what is discussed in rfc 8955 rather than trying to restate things too much.

Again, the "destination must be present as a component". Not a requirement, but applicable for customer route validation.

"how to order filters prior to transmission to another peer". I don't think that's what's intended at all. If the intent is "try to order things and push them on the wire in a sorted way to try to reduce temporary rule conflicts", this is ignoring all sorts of other edge conditions that happen when rules may interact badly. Needs significant discussion.

Section 3

Length of nexthop as zero is reasonable, but will likely raise a point about the redirect-to-ip feature which uses it in "legacy" mode.

NLRI length discussion point: FSv1 lets you encode the length in one or two octets. It's messy, but at least understood now. Do we want to just go with the simpler "always 2" as in the draft?

Identifier: As we discussed previously, why do we think we want this?

I'm a bit confused at the "types" as I'm doing my top to bottom read, but may come back to that.

For the things like ip header subtlv,, "subtlv type" is intended to be "component" from fsv1. I think we want to keep that naming.

The sub-tlv length of 1 octet will mean we can't encode same things we can do so in fsv1. For example, a very long port list can exceed 255 bytes, and would have encoded fine in fsv1.

Discussion point: IP prefix encoding in ipv6 is different than ipv4. From a parser standpoint, when we're talking about "ip header" types for traditional fsv1, the afi acts to disambiguate the encoding. However, since we're going to be looking at applications that can dig into packet contents from a different layer, e.g. L2, we will need the ability to say that a given bit of payload might be ipv4 or ipv6 and clearly distinguish those. We can't do this with the overloaded type without some other way to trigger which decoder is used - or simply use different component types. Similar considerations will apply for things like icmp(v6) types.

Discussion point: The codes assigned for things outside of the fsv1 range should be considered based on how we want sort order to be impacted. We should thus be cautious against simply doing FCFS. Very likely we'll want to split the larger 16-bit range into things that are application specific to permit insertion of new components over time in a way that provides good default ordering. Explicit user ordering will help.

MPLS label match: Matching one label is a start, but it may be necessary for some applications to match a vector of labels. E.g. RFC 7274 encoding.

I'm unclear on the action of the "filter error handling". Is this actually a match criteria, or an action?

2.1
ECA as "event match condition action", the "match" in there confuses the acronym. Is this a WKA?

There's a lot of text in here that erroneously requires a destination prefix component.

The definition of fsv1 rules and ordering is trying to talk about nlri construction but does so quite awkwardly.

The actions with hex values are confusing. Were those intended to refer to extended communities? If so, that's not clear.

The diagram attempts to illustrate the rule ordering but does a disservice in trying to talk about how the sorting works. It's better to just stick with talking about the sort algorithm and the consequence of component ID orders and how that impacts rules.

Section 2 2.2

Talking about permit all as rule zero and then immediately saying user rules are down with lowest numerical has best precedence means that you would only ever permit everything. That's not what you intend.

It's rather unclear at the point where "rule" is even mentioned what it's intended to cover. A flowspec term set?

What this text is trying accomplish is describe the sort order, and relative precedence of fsv1 vs. fsv2 vs. default rules. Needs work.

The comment about whether the system will accept rules or not based on capabilities should be bubbled up as a higher level concept. Once we're into enumerating what rules are, the presumption is that we should have negotiated that afi/safi.

The default action of drop is the opposite of what fsv1 does. Probably not a good idea.

4.2

FSv1 doesn't talk about action rule ordering, and is part of the headache we want to deal with by no longer using the extended community encodings.

However, the idea of "translate the extended community into the internal tlv code points again puts deep significance on the code point numbering and we'll want to talk about that.