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
[bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ -- 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 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). [...] 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? Section 4 Please expand I-PMSI on first usage. When following this procedure, the PTA of the S-PMSI A-D route may specify a tunnel, or may specify "no
