Explicit Tracking with Wildcard Routes in Multicast VPN
draft-ietf-bess-mvpn-expl-track-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-02-07
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-01-28
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-01-04
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-12-07
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-12-07
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-12-06
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-12-03
|
13 | (System) | RFC Editor state changed to EDIT |
2018-12-03
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-12-03
|
13 | (System) | Announcement was received by RFC Editor |
2018-12-03
|
13 | (System) | IANA Action state changed to In Progress |
2018-12-03
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-12-03
|
13 | Cindy Morgan | IESG has approved the document |
2018-12-03
|
13 | Cindy Morgan | Closed "Approve" ballot |
2018-12-03
|
13 | Cindy Morgan | Ballot approval text was generated |
2018-12-03
|
13 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-12-03
|
13 | Martin Vigoureux | Ballot approval text was generated |
2018-12-02
|
13 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss points! [original COMMENT section preserved, though I believe that they have all been addressed via email clarification … [Ballot comment] Thank you for addressing my Discuss points! [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. |
2018-12-02
|
13 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2018-11-29
|
13 | Benjamin Kaduk | [Ballot discuss] Thank you for addressing my original DISCUSS point! The updates in the -13 include new Updates headers for RFCs 7582 and 7900, which … [Ballot 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. |
2018-11-29
|
13 | Benjamin Kaduk | [Ballot comment] [original COMMENT section preserved, though I believe that they have all been addressed via email clarification or in the -13] Section 1 … [Ballot 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. |
2018-11-29
|
13 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2018-11-29
|
13 | Mirja Kühlewind | [Ballot comment] Thanks for addressing my discuss! |
2018-11-29
|
13 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2018-11-28
|
13 | Suresh Krishnan | [Ballot comment] Thanks for addressing my DISCUSS |
2018-11-28
|
13 | Suresh Krishnan | [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss |
2018-11-28
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-11-28
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-11-28
|
13 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-13.txt |
2018-11-28
|
13 | (System) | New version approved |
2018-11-28
|
13 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-11-28
|
13 | Eric Rosen | Uploaded new revision |
2018-10-25
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-10-25
|
12 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-10-24
|
12 | Adam Roach | [Ballot comment] Thanks for the work everyone did on this document. --------------------------------------------------------------------------- Please expand the following acronyms upon first use and in the abstract; see … [Ballot comment] Thanks for the work everyone did on this document. --------------------------------------------------------------------------- Please expand the following acronyms upon first use and in the abstract; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - MVPN - Multicast VPN - I-PMSI - ??? - P2MP - Point-to-Multipoint |
2018-10-24
|
12 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-10-24
|
12 | Alvaro Retana | [Ballot comment] I have some non-blocking comments: (1) §3: The rules for finding a "match for reception" in [RFC6625] are hereby … [Ballot comment] I have some non-blocking comments: (1) §3: The rules for finding a "match for reception" in [RFC6625] are hereby modified as follows: When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies "no tunnel information present". There are other RFCs that update [RFC6625] and that modify the rules for finding a "match for reception". See, e.g., [RFC7582] and [RFC7900]. When applying those modified rules, it is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies "no tunnel information present". This text is also Updating rfc7582 and rfc7900 (and others?) that Updated rfc6625. This document should then be marked to Update those other RFCs explicitly. (2) How is this phrase intended to be interpreted: "the following procedure can be used if and only if it is known that the egress nodes support the optional LIR-pF flag" (§4)? I ask because, even though there's no rfc2119 language, I would be inclined to interpret "if and only if" as an absolute requirement: just like a MUST. However, later in the same section there is normative language that doesn't seem to match: "this procedure...if there are egress nodes that do not support the LIR-pF flag, and hence SHOULD NOT be used in that case." I think that, in the best case, there may be some confusion in the text -- it would be good to clarify by maybe not using an expression as absolute as "if and only if". (3) §5.1, Case 3: "...LIR-pF is set. The egress node MUST follow whatever procedures are required by other specifications, based on the match for reception. If the egress node supports the LIR-pF flag, it MUST also follow the procedures of Section 5.2." The text above seems to account for the case where the egress node doesn't support the LIR-pF flag in the first sentence quoted. However, if the node doesn't support the flag, it can't be assumed that it has knowledge of this document...which means that we shouldn't use normative language to instruct those nodes to do anything. Also, the specification of "whatever procedures are required by other specifications" is too vague for being normative. s/MUST/must (4) §2: s/Since an ingress node that sets the LIR-pF flag is also REQUIRED to set the LIR flag,/Since an ingress node that sets the LIR-pF flag is also required to set the LIR flag, The normative behavior is already specified above ("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"). I know that MUST = REQUIRED, but in this case the sentence is just stating a fact. |
2018-10-24
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-10-24
|
12 | Suresh Krishnan | [Ballot discuss] * Section 5.2. In the NLRI format it is not clear what the length of the "Ingress PE's IP address" field is supposed … [Ballot discuss] * Section 5.2. In the NLRI format it is not clear what the length of the "Ingress PE's IP address" field is supposed to be. i.e. what address families does it support and how do we determine what sort of address follows since there is no length field in front. |
2018-10-24
|
12 | Suresh Krishnan | [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan |
2018-10-24
|
12 | Spencer Dawkins | [Ballot comment] Keeping in mind that reading multicast specifications now is like reading the denser MPLS specifications 10-15 years ago, even with the forest of … [Ballot comment] Keeping in mind that reading multicast specifications now is like reading the denser MPLS specifications 10-15 years ago, even with the forest of unfamiliar terms in the Introduction, you manage to explain clearly what the problems being addressed are. Thank you for that effort. I support Mirja's Discuss, specifically because if this ever goes wrong, the people writing this spec probably know the most about what to do about it. If you can provide guidance, it will probably be better guidance than operators will get from anyone else. (And please take this as a compliment!) |
2018-10-24
|
12 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-10-24
|
12 | Ben Campbell | [Ballot comment] Thanks for the work on this! *** Substantive Comments *** I support Mirja's DISCUSS. - There is an IPR disclosure with possible royalties. … [Ballot comment] Thanks for the work on this! *** Substantive Comments *** I support Mirja's DISCUSS. - There is an IPR disclosure with possible royalties. The shepherd report says there were no WG objections. How was the disclosure communicated? For example, was the WG reminded of the disclosure at WGLC? *** Editorial Comments *** §3: - Part way through the section, starting with "We also introduce a new notion, the "match for tracking":", there is a section of text that has a significantly different tone from the rest of the draft. It switches more of a lecture style, then switches back. I suggest an edit pass to keep a consistent tone. (I know this is a question of style, and I will not press it further if people prefer not to change it.) - 2 paragraphs starting with "For a given C-flow..." Why is this indented? |
2018-10-24
|
12 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-10-24
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-10-24
|
12 | Mirja Kühlewind | [Ballot discuss] In section 9 (security considerations): Thanks for discussing network load here! However, I find this sentence a bit unsatisfactory: „The specification of … [Ballot discuss] In section 9 (security considerations): Thanks for discussing network load here! However, I find this sentence a bit unsatisfactory: „The specification of counter-measures for this problem is outside the scope of this document.“ Isn’t there any easy way to make some more recommendations for counter measures that could be discussed here? E.g. implement some rate limiting or filtering. Or only accept LIR-PF request from preconfigured hosts (given that LIR-PF support must anyway be pre-configured)? I’m not an expert on this topic and therefore don’t know if any of such recommendations make sense, however, I would quickly like to discuss if it is potentially possible to say more than what’s current said. Thanks! |
2018-10-24
|
12 | Mirja Kühlewind | [Ballot comment] Some other minor comments: 1) section 2: „Use of this flag in the PTA carried by other route types is outside the … [Ballot comment] Some other minor comments: 1) section 2: „Use of this flag in the PTA carried by other route types is outside the scope of this document. Use of this flag in the PTA carried by an S-PMSI A-D routes whose NLRI does not contain a wildcard is outside the scope of this document.“ Maybe you also want to say something like „The flag SHOULD be ignored in these cases.“..? 2) section 3 s/The result (if any) is the match for tracking“/The result (if any) is the “match for tracking“/ (missing quotes) |
2018-10-24
|
12 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2018-10-23
|
12 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-10-22
|
12 | Benjamin Kaduk | [Ballot discuss] This document places normative requirements on new tunnel types but does not indicate this in a way that someone specifying a new tunnel … [Ballot 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! |
2018-10-22
|
12 | Benjamin Kaduk | [Ballot 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 … [Ballot 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. |
2018-10-22
|
12 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-10-17
|
12 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-10-11
|
12 | Brian Carpenter | Request for Telechat review by GENART Completed: Ready. Reviewer: Brian Carpenter. Sent review to list. |
2018-10-11
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2018-10-11
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2018-10-10
|
12 | Cindy Morgan | Placed on agenda for telechat - 2018-10-25 |
2018-10-10
|
12 | Martin Vigoureux | Ballot has been issued |
2018-10-10
|
12 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-10-10
|
12 | Martin Vigoureux | Created "Approve" ballot |
2018-10-10
|
12 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-10-10
|
12 | Martin Vigoureux | Ballot writeup was changed |
2018-10-09
|
12 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-10-09
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-10-09
|
12 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-12.txt |
2018-10-09
|
12 | (System) | New version approved |
2018-10-09
|
12 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-10-09
|
12 | Eric Rosen | Uploaded new revision |
2018-10-09
|
11 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-10-08
|
11 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-10-08
|
11 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-bess-mvpn-expl-track-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-bess-mvpn-expl-track-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the P-Multicast Service Interface (PMSI) Tunnel Attribute Flags registry on the Border Gateway Protocol (BGP) Parameters registry page located at: https://www.iana.org/assignments/bgp-parameters/ a single, new value is to be added to the registry as follows: Value: 2 Name: [ see below ] Reference: [ RFC-to-be ] IANA Question --> What should the "Description" for this attribute flag be? Please see the registry at: https://www.iana.org/assignments/bgp-parameters/ for other examples of how the description of other P-Multicast Service Interface (PMSI) Tunnel Attribute Flags has been specified in the past. The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-10-05
|
11 | Christian Huitema | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Christian Huitema. Sent review to list. |
2018-10-04
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2018-10-04
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2018-10-04
|
11 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-11.txt |
2018-10-04
|
11 | (System) | New version approved |
2018-10-04
|
11 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-10-04
|
11 | Eric Rosen | Uploaded new revision |
2018-10-02
|
10 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. Sent review to list. |
2018-09-27
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2018-09-27
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2018-09-27
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2018-09-27
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2018-09-25
|
10 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-10.txt |
2018-09-25
|
10 | (System) | New version approved |
2018-09-25
|
10 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-09-25
|
10 | Eric Rosen | Uploaded new revision |
2018-09-25
|
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-09-25
|
09 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-10-09): From: The IESG To: IETF-Announce CC: draft-ietf-bess-mvpn-expl-track@ietf.org, bess-chairs@ietf.org, martin.vigoureux@nokia.com, bess@ietf.org, stephane.litkowski@orange.com … The following Last Call announcement was sent out (ends 2018-10-09): From: The IESG To: IETF-Announce CC: draft-ietf-bess-mvpn-expl-track@ietf.org, bess-chairs@ietf.org, martin.vigoureux@nokia.com, bess@ietf.org, stephane.litkowski@orange.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Explicit Tracking with Wild Card Routes in Multicast VPN) to Proposed Standard The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Explicit Tracking with Wild Card Routes in Multicast VPN' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-10-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MVPN specifications provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, and 7524. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2807/ |
2018-09-25
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-09-25
|
09 | Martin Vigoureux | Last call was requested |
2018-09-25
|
09 | Martin Vigoureux | Ballot approval text was generated |
2018-09-25
|
09 | Martin Vigoureux | Ballot writeup was generated |
2018-09-25
|
09 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation |
2018-09-25
|
09 | Martin Vigoureux | Last call announcement was generated |
2018-09-12
|
09 | Carlos Pignataro | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Carlos Pignataro. Sent review to list. |
2018-09-10
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Carlos Pignataro |
2018-09-10
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Carlos Pignataro |
2018-06-19
|
09 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2018-05-07
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Tony Przygienda |
2018-05-07
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Tony Przygienda |
2018-05-07
|
09 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2018-04-20
|
09 | Stephane Litkowski | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document requests Standard Track. The shepherd thinks that it is accurate as the document introduces some procedures and encoding that require interoperability between implementations. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document clarifies the explicit tracking procedures in Multicast VPNs. The existing documents are leaving ambiguity for some scenarios that are clarified by this document. In addition, the document provides new optimized procedures to request explicit tracking of individual flows when wildcard S-PMSIs are used. Working Group Summary There was no real controversy on this document. Some technical points have been discussed and resolved with the WG consensus. Document Quality There is no implementation yet as far as we know. The draft-ietf-bier-mvpn has a normative dependency with this document. There was no opposition in the WG to progress the document without implementations to help the BIER document progressing. Personnel Stephane Litkowski is the document shepherd. Martin Vigoureux is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has reviewed deeply the document and provided comments both on the readability and the technical aspects. All the comments have been addressed by the authors in the last available revision. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concern (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. One IPR has been disclosed on this document. The WG did not raise any concern about it. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The shepherd thinks that there is good level of consensus including people from various affiliations. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There is one remaining nits pointed by the tool on RFC7524 not mentioned in the abstract. But it looks more a tool issue as it is correctly mentioned. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No, all are RFCs (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward reference (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document is expected to update several RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA section is clearly written. A single bit allocation is required by this document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2018-04-20
|
09 | Stephane Litkowski | Responsible AD changed to Martin Vigoureux |
2018-04-20
|
09 | Stephane Litkowski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-04-20
|
09 | Stephane Litkowski | IESG state changed to Publication Requested |
2018-04-20
|
09 | Stephane Litkowski | IESG process started in state Publication Requested |
2018-04-20
|
09 | Stephane Litkowski | Changed document writeup |
2018-04-19
|
09 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-09.txt |
2018-04-19
|
09 | (System) | New version approved |
2018-04-19
|
09 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-04-19
|
09 | Eric Rosen | Uploaded new revision |
2018-04-19
|
08 | Stephane Litkowski | Changed document writeup |
2018-03-17
|
08 | Stephane Litkowski | Added to session: IETF-101: bess Tue-1550 |
2018-02-26
|
08 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-08.txt |
2018-02-26
|
08 | (System) | New version approved |
2018-02-26
|
08 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-02-26
|
08 | Eric Rosen | Uploaded new revision |
2018-02-20
|
07 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-07.txt |
2018-02-20
|
07 | (System) | New version approved |
2018-02-20
|
07 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-02-20
|
07 | Eric Rosen | Uploaded new revision |
2018-01-31
|
06 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-06.txt |
2018-01-31
|
06 | (System) | New version approved |
2018-01-31
|
06 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-01-31
|
06 | Eric Rosen | Uploaded new revision |
2018-01-31
|
05 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-05.txt |
2018-01-31
|
05 | (System) | New version approved |
2018-01-31
|
05 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-01-31
|
05 | Eric Rosen | Uploaded new revision |
2018-01-16
|
04 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-04.txt |
2018-01-16
|
04 | (System) | New version approved |
2018-01-16
|
04 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2018-01-16
|
04 | Eric Rosen | Uploaded new revision |
2017-12-07
|
03 | Martin Vigoureux | Notification list changed to none from Stephane Litkowski <stephane.litkowski@orange.com> |
2017-12-07
|
03 | Martin Vigoureux | Notification list changed to Stephane Litkowski <stephane.litkowski@orange.com> |
2017-12-07
|
03 | Martin Vigoureux | Document shepherd changed to Stephane Litkowski |
2017-09-29
|
03 | Martin Vigoureux | Notification list changed to none from Thomas Morin <thomas.morin@orange.com> |
2017-09-29
|
03 | Martin Vigoureux | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-09-29
|
03 | Martin Vigoureux | Notification list changed to Thomas Morin <thomas.morin@orange.com> |
2017-09-29
|
03 | Martin Vigoureux | Document shepherd changed to Thomas Morin |
2017-09-22
|
03 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-03.txt |
2017-09-22
|
03 | (System) | New version approved |
2017-09-22
|
03 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Jayant Kotalwar , Eric Rosen , Andrew Dolganow |
2017-09-22
|
03 | Eric Rosen | Uploaded new revision |
2017-07-10
|
02 | Thomas Morin | IETF WG state changed to In WG Last Call from WG Document |
2017-06-05
|
02 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-02.txt |
2017-06-05
|
02 | (System) | New version approved |
2017-06-05
|
02 | (System) | Request for posting confirmation emailed to previous authors: Zhaohui Zhang , Andrew Dolganow , bess-chairs@ietf.org, Jayant Kotalwar , Eric Rosen |
2017-06-05
|
02 | Eric Rosen | Uploaded new revision |
2016-12-12
|
01 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-01.txt |
2016-12-12
|
01 | (System) | New version approved |
2016-12-12
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Andrew Dolganow" , bess-chairs@ietf.org, "Zhaohui Zhang" , "Jayant Kotalwar" , "Eric Rosen" |
2016-12-12
|
01 | Eric Rosen | Uploaded new revision |
2016-07-20
|
00 | Thomas Morin | Changed consensus to Yes from Unknown |
2016-07-20
|
00 | Thomas Morin | Intended Status changed to Proposed Standard from None |
2016-06-20
|
00 | Martin Vigoureux | This document now replaces draft-dolganow-bess-mvpn-expl-track instead of None |
2016-06-20
|
00 | Eric Rosen | New version available: draft-ietf-bess-mvpn-expl-track-00.txt |