Hi Eric, Sorry for the slow response -- the timing of when this came in interacted poorly with my travel/vacation schedule.
On Thu, Nov 15, 2018 at 07:43:31PM +0000, Eric Rosen wrote: > > On 10/22/2018 9:41 PM, Benjamin Kaduk wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This document places normative requirements on new tunnel types but does > > not indicate this in a way that someone specifying a new tunnel type would > > be forced to see. This occurs both in Section 5.2: > > > > o When additional tunnel types are defined, the specification for > > how MVPN is to use those tunnel types must also specify how to > > construct the PTA of a Leaf A-D route that is originated in > > response to the LIR-pF flag. As an example, see [BIER-MVPN]. > > > > and in Section 6: > > > > If L's PTA specifies a tunnel type not mentioned above, the > > specification for how MVPN uses that tunnel type must specify the > > actions that N is to take upon receiving L. As an example, see > > [BIER-MVPN]. > > > > I think the best way to do this would be to have IANA Considerations > > updating the registration procedure for > > P-Multicast Service Interface (PMSI) Tunnel Type codepoints to note that > > new registrations must include this information. It might also suffice to > > call out the existence of these requirements in the portion of the > > Introduction that discusses how this document Updates RFC 6514 (though, per > > the COMMENT section, this portion of the Introduction doesn't exist in a > > good form yet). > > > > Thank you for providing the BIER example, though -- it is helpful to see > > how the requirement plays out in practice! > > Well, let me make a counter-proposal :-) > > In section 2, I'd like to add the following text: > > Use of the LIR-pF flag in a PTA whose tunnel type is not one of the > types listed in Section 5 of [RFC6514] is outside the scope of this > document. Presumably, if an additional tunnel type is used, there > will be a specification for how that tunnel type is used in MVPN. If > it is desired to use that tunnel type along with the LIR-pF flag, > that specification will have to specify the rules for using the LIR- > pF flag with that tunnel type. As an example, see [BIER-MVPN]. In > the absence of such a specification, the LIR-pF flag SHOULD NOT be > set in a PTA that specifies that tunnel type, and its value SHOULD be > ignored. > > And for section 5.2: > > o If the tunnel type of the PTA attached to the match for tracking/ > reception is any other tunnel type, the rules for constructing the > PTA of a Leaf A-D route that is originated in response to the > LIR-pF flag are outside the scope of this document. Presumably > there will be a specification for how that tunnel type is used in > MVPN. If it is desired to use that tunnel type along with the > LIR-pF flag, that specification will have to specify the rules for > constructing the PTA. As an example, see [BIER-MVPN]. In the > absence of such a specification, the LIR-pF flag in a PTA > specifying that tunnel type SHOULD be ignored. > > (The context will make it clear that "any other tunnel type" is "any > tunnel type not mentioned in Section 5 of RFC 6514".) > > And for section 6: > > If L's PTA specifies a tunnel type not mentioned above, presumably > there is a specification for how MVPN uses that tunnel type. If the > LIR-pF flag is to be used with that tunnel type, that specification > must specify the actions that N is to take upon receiving L. As an > example, see [BIER-MVPN]. In the absence of such a specification, > the LIR-pF flag SHOULD BE ignored. > > > (The context will make it clear that "a tunnel type not mentioned above" > is "any tunnel type not mentioned in Section 5 of RFC 6514".) > > I think that these passages address your issue. If someone wants to use > a new tunnel type with MVPN and they don't care about the LIR-pF flag, > then they don't have to do anything, and the flag will be ignored. If > they do care about LIR-pF, then they'll look at this document and see > just what they need to specify. > > What do you think? That's a fine counter-proposal; I've updated my ballot position accordingly (but we may need more discussion about the Updates: 7582 7900 headers). I also appreciate the discussion and updates with regards to my comments below, and I don't have any additional comments about them. Thanks again! -Benjamin > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1 > > > > This document clarifies the procedures for originating and receiving > > S-PMSI A-D routes and Leaf A-D routes. This document also adds new > > procedures to allow more efficient explicit tracking. The procedures > > being clarified and/or extended are discussed in multiple places in > > the documents being updated. > > > > This is in effect saying to the reader, "you must read the updated > > document(s) in their entirety and decide for yourself whether a procedure > > being updated is described", which is perhaps not the most friendly thing > > to be doing. > > Your point is well-taken, but unfortunately RFC 6514 is not organized in > a manner that makes it really feasible to point out each place that > might be relevant. If I tried to find every place in RFC 6514 that > might be affected, I'd probably end up omitting a few, and that would > introduce a bug into the document. > > If someone is adding LIR-pF support to an existing implementation, this > is not really a big problem, because they just have to find the places > in their code where the S-PMSI and Leaf A-D routes are handled. > > > > > Section 2 > > > > If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR > > flag of that PTA MUST also be set. > > > > What do I do if I receive a PTA in violation of the MUST? > > I've change the above text to: > > If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the > originator of that route MUST also set the LIR flag. If the PTA of a > received wildcard S-PMSI A-D route has LIR-pF set but does not have > LIR set, the receiver MUST log the fact that the flags appear to have > been improperly set. However, the route MUST then be processed > normally (as if both flags were set), as specified in this document. > > (The reason for setting both flags is that it helps you to detect the > presence of an egress node that doesn't support LIR-pF. But if a > receiving node supports LIR-pF, it doesn't really matter if LIR is set > or not, so there's no reason to do anything more than log the issue.) > > > > > Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD > > NOT be set unless it is known that all the PEs that are to receive > > the route carrying the PTA support the flag. How this is known is > > outside the scope of this document. > > > > Maybe remind us what a PE that doesn't support this flag will do if it > > happens to receive a PTA with it set? (I see discussion below of the state > > at the ingress node in this case, but not an explicit confirmation of what > > egress nodes do.) > > A PE that doesn't support the LIR-pF flag will just ignore it. But it > will respond to the LIR flag, and the response will enable the ingress > node to determine that the egress node doesn't have LIR-pF support. I > think this is discussed in Section 2. > > > It would also be nice to give non-normative examples of > > how a sender might know that receivers support the flag. > > I've added the following text: > > (Typically, this means that the ability to set this flag would be > controlled by a configuration knob, and operators should not set this > knob unless they know that all the PEs support this feature.) > > > > > Section 3 > > > > The rules for finding a "match for reception" in [RFC6625] are hereby > > modified as follows: > > > > Maybe give a section reference too? (Especially since 6625 does not use > > the abbreviated version we define here, and instead writes "Finding the > > Match for Data Reception".) > > The immediately preceding paragraph begins: > > Section 3.2 of [RFC6625] specifies a set of rules for finding the > S-PMSI A-D route that is the "match for data reception" (or more > simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G) > state. > > I think that provides what you're asking for? > > > > > For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for > > tracking" is chosen as follows. Ignore any S-PMSI A-D route that > > has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies > > "no tunnel information present", but does not have either LIR or > > LIR-pF set. (That is, DO NOT ignore an S-PMSI A-D route that has > > > > I think this would be clearer as "and has neither LIR nor LIR-pF set" -- > > the "but" can easily lead the reader astray. > > > > a PTA specifying "no tunnel information present" unless its LIR > > and LIR-pF bits are both clear). [...] > > Okay, I've made that change. > > > > > Note that the procedure for finding the match for tracking takes > > into account S-PMSI A-D routes whose PTAs specify "no tunnel > > information present" and that have either LIR or LIR-pf set. The > > procedure for finding the match for reception ignores such routes. > > > > Why are we talking about this like LIR and LIR-pF can be set independently, > > when just last page we said that if LIR-pF is set, LIR MUST be set? > > So that things will still work if some ingress node sets LIR-pF but > fails to set LIR. > > > > > Section 4 > > > > Please expand I-PMSI on first usage. > > Done. > > > > > When following this procedure, the PTA of the S-PMSI A-D route > > may specify a tunnel, or may specify "no tunnel information > > present". The choice between these two options is determined by > > considerations that are outside the scope of this document. > > > > Could you give some examples of what sort of things might be involved in > > making that choice? > > This really depends upon how the operator chooses to assign flows to > tunnels. That involves a whole bunch of inter-related considerations > that really are not within the scope of this document. > > > > > Section 5.3 > > > > Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel, > > and also has LIR-pF set. [...] > > > > nit: is this this "route being forwarded" (i.e., where the ABR/ASBR acts as > > egress) or the "after forwarding route" (i.e., where the ABR/ASBR acts as > > ingress)? > > Good catch! We're talking here about the PTA as received, but that is > not at all clear from the text. I'll make some adjustments to make that > clear. > > > > > As a result of propagating such an S-PMSI A-D route, the egress ABR/ > > ASBR may receive one or more Leaf A-D routes that correspond to that > > S-PMSI A-D route. [...] > > > > Just to check my understanding (no document change requested), this > > correspondance is determined by the NLRI in the Leaf A-D route matching the > > NLRI from the S-PMSI A-D route? > > More precisely, the "route key" field from the Leaf A-D route's NLRI > matches the NLRI from the S-PMSI A-D route. > > > > > The "global administrator" field of the modified RT will be set to > > the IP address taken either from the S-PMSI A-D route's next hop > > field ([RFC6514]), or from its Segmented P2MP Next Hop Extended > > Community ([RFC7524]). > > > > How do I choose which one to use? > > I'll add text stating that the address from the EC is used if the EC is > present, otherwise the address from the next hop field is used. > > > > > Section 6 > > > > then the action taken by N when it receives L is a local matter. In > > this case, the Leaf A-D route L provides N with explicit tracking > > information for the flow identified by L's NLRI. However, that > > information is for management/monitoring purposes and does not have > > an effect on the flow of multicast traffic. > > > > I would prefer to say "does not necessarily have an effect". > > How about "does not have any direct effect on"? > > > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
