Hi Eric, Thanks a lot for the update. Couple of more comments:
Section 2: I still have some concern about these two sentences: 1)"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." 2)"By setting LIR as well as LIR-pF, one forces a response to be sent by an egress node that does not support LIR-pF." [SLI] As per 1), the situation described in 2) should not happen Do we agree that this should not happen ? I think we can make the text more clear about the implications of setting the LIR-pf in a partial deployment scenario. We can add a text like after 1): "Setting the LIR-pF in a network where only a subset of PEs supports it prevents the ingress PE to have a complete view of the receiving PEs." We may also modify 2) as follows: OLD By setting LIR as well as LIR-pF, one forces a response to be sent by an egress node that does not support LIR-pF. It is possible to tell from that response that the egress node does not support LIR-pF. This may be an aid to troubleshooting. NEW By setting LIR as well as LIR-pF, one forces a response to be sent by an egress node that does not support LIR-pF. It is possible to tell from that response that the egress node does not support LIR-pF. As the support of LIR-pF is recommended on all PEs, this situation should not happen. However, in case of deployment error, this may be an aid to troubleshooting. Section 5.2: "The encoding of these Leaf A-D routes is similar to the encoding of the Leaf A-D routes described in section 6.2.2 of [RFC7524], which were designed for the support of "global table multicast". However, that document sets the RD to either 0 or -1; following the procedures of this document, the RD will never be 0 or -1. Therefore Leaf A-D routes constructed according to the procedures of this section can always be distinguished from the Leaf A-D routes constructed according to the procedures of section 6.2.2 of [RFC7524]. Also, Leaf A-D routes constructed according to the procedures of this section are VPN-specific routes, and will always carry an IP-address- specific Route Target, as specified in [RFC6514]." [SLI] I'm wondering if this text is still required as we do not modify the RD compared to RFC6514. Brgds, -----Original Message----- From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Eric C Rosen Sent: Tuesday, February 20, 2018 19:58 To: bess@ietf.org Subject: Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt The -07 rev of draft-ietf-bess-mvpn-expl-track has the following changes from the -06 version: 1. The draft now says that it updates RFCs 6514 and 7524 as well as RFC 6625. I think this is now necessary because the draft modifies the ingress node processing of received Leaf A-D routes that carry a PTA with the LIR-pF flag set. I'm not sure what the objective criteria are supposed to be for "updates", but it makes sense that anyone trying to implement RFC 6514 or 7524 read this document as well. 2. There are a number of textual changes and clarifications in response to comments by Stephane Litkowski. 3. The boilerplate is updated to be in accord with RFC 8174. 4. There is now a warning that the LIR-pF flag should not be set unless it is known a priori that all nodes support it. 5. It is now REQUIRED that the LIR flag be set whenever the LIR-pF flag is set in the PTA carried by an S-PMSI A-D route. 6. The peculiar idea of modifying the RD of a Leaf A-D route originated in response to the LIR-pF flag has been eliminated. (Mea culpa.) 7. A Leaf A-D route originated in response to the LIR-pF flag is now REQUIRED to carry a PTA with the LIR-pF flag set. 8. Text has been added specifying when such a PTA should specify "no tunnel info" and when it should specify a tunnel type. 9. Text has been added to deal with the case where a wildcard S-PMSI A-D route has (a) LIR-pF set in its PTA, and (b) also specifies a tunnel type of Ingress Replication. The new text allows a Leaf A-D route sent in response to the LIR-pF bit to carry a PTA specifying an MPLS label. 10. Text has been added to say that the specifications for how to use new "tunnel types" with MVPN must specify procedures for originating Leaf A-D routes in response to S-PMSI A-D routes whose PTAs specify the given tunnel type and have the LIR-pF flag set. An informational reference to the bier-mvpn draft has been added as an example. 11. A section has been added discussing how an ingress node responds to a Leaf A-D route that carries a PTA with the LIR-pF bit set. I hope those who are interested will review the diffs and send feedback to the list. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
