Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
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 +, 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 >
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
Benjamin, I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues. Please let me know whether this is the case. And thank you for doing such a careful review. Eric On 10/22/2018 9:41 PM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bess-mvpn-expl-track-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0=UWa2_MZELEQCZBxgLuEXDrhFGiFhDaSLecKezEgQJSk= > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack_=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0=Zs4cZ41OK1XktcOKuVjcsMkGQmpuzOc9fWuTjx1HQZY= > > > > -- > 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! > > > -- > 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. > > 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? > > 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.) It would also be nice to give non-normative examples of > how a sender might know that receivers support the flag. > > 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".) > >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 >
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
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? > > > -- > 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
