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&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0&s=UWa2_MZELEQCZBxgLuEXDrhFGiFhDaSLecKezEgQJSk&e= > 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_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0&s=Zs4cZ41OK1XktcOKuVjcsMkGQmpuzOc9fWuTjx1HQZY&e= > > > > ---------------------------------------------------------------------- > 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 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? > > 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)? > > 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? > > 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? > > 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". > > Section 9 > > I agree with the secdir reviewer that some mitigation for the new problem > indicated is appropriate. (Some justification for why the problem is > insoluble in the scope of this document might also suffice.) > > Additionally, it seems that the mechanisms here can require more state to > be maintained in the SP network than a pure 6513/6514 solution would, and > that could be worth mentioning (along the lines of 6513's mention of the > potential for overload when multicast activity exceeds expectations). > Similarly, additional implementation limitations may be advisable. > > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
