Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-mvpn-expl-track-13: 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: ---------------------------------------------------------------------- Thank you for addressing my original DISCUSS point! The updates in the -13 include new Updates headers for RFCs 7582 and 7900, which may or may not call for additional IESG eyes on the changes. Just from looking at the diff, it's not entirely clear to me what about those documents is being updated. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [original COMMENT section preserved, though I believe that they have all been addressed via email clarification or in the -13] 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