Hi Eric, I'm fine with the version 8. Thanks a lot for the changes.
Speaking as WG chair, Due to the substantial changes in the document, I will initiate a new short WGLC for this document soon. Brgds, -----Original Message----- From: Eric C Rosen [mailto:ero...@juniper.net] Sent: Monday, February 26, 2018 21:40 To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org Subject: Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt On 2/22/2018 3:10 AM, stephane.litkow...@orange.com wrote: > Hi Eric, > > > > Thanks a lot for the update. And thank you for your continued attention to the details. I have posted -08. Responses in-line. > > 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. [Eric] In revision -08, I have reworked this text to indicate what will happen in the case of deployment errors, and how such errors can be detected. However, I wouldn't necessarily guarantee that there are no corner cases in which a deployment error might go undetected. > > > > > > > > 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. > [Eric] There are two situations in which an ingress node might receive a Leaf A-D route whose route key field is not identical to the NLRI of a current x-PMSI A-D route originated by the ingress node. One situation is specified in RFC 7524. The other is specified in the explicit tracking draft. I think it is useful to point out that the ingress node can distinguish between these two cases when it receives such a Leaf A-D route. _________________________________________________________________________________________________________________________ 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
