Hi Thomas, Martin > Before adopting this draft, we would like hear people actually experiencing > pain > related to not solving this issue and hear about implementations in actual > products.
In a network where some BGP-VPLS PEs have ability to insert CW and some do not, not implementing section 3 has potential to cause the PW to not come up or cause dropped packets (depending on implementation). Section 3 of this draft is implemented in JunOS. See last paragraph on http://www.juniper.net/techpubs/en_US/junos14.1/topics/concept/vpls-bgp-control-word-overview.html This was implemented in response to a specific-network-deployment-issue. The key aspect of RFC4761 that necessitates the text of section 3 of this draft is that the NLRI-advertising-PE is predicating on all other PEs in the same VPLS, that they must or must-not insert the CW, for example, regardless of whether they have the capability or not. [See https://tools.ietf.org/html/rfc4761#section-3.2.4] This is in contrast to the proposed modification (for a different purpose) where this PE is just advertising its ability (https://tools.ietf.org/html/draft-ietf-bess-fat-pw-bgp-00#section-2) The proposed text in section 3 provides a way around presumption of other-PEs' abilities. Section 4 provides an extension of the same intent for a deployment where the transport LSP maybe a p2mp LSP. Section 5 generalizes the previous sections as deployed to multi-homing scenarios. Both p2mp and multi-homing have some deployments and may run into the issue. Regards Ravi > -----Original Message----- > From: thomas.mo...@orange.com [mailto:thomas.mo...@orange.com] > Sent: Monday, October 5, 2015 12:29 AM > To: bess@ietf.org; draft-singh-bess-bgp-vpls-control-fl...@tools.ietf.org; > Ravi > Singh <ra...@juniper.net>; Kireeti Kompella <kire...@juniper.net>; > senad.palislamo...@alcatel-lucent.com > Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags > > Authors of draft-singh-bess-bgp-vpls-control-flags, working group, > > The support base for this proposal is not large. > Before adopting this draft, we would like hear people actually experiencing > pain > related to not solving this issue and hear about implementations in actual > products. > > Let's consider this poll for adoption open until we hear more. > > Best, > > Thomas/Martin > > > thomas.mo...@orange.com : > > Hello working group, > > > > This email starts a two-week poll on adopting > > draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item. > > > > Please send comments to the list and state if you support adoption or > > not (in the later case, please also state the reasons). > > > > This poll runs until **September 29th**. > > > > > > *Coincidentally*, we are also polling for knowledge of any IPR that > > applies to this draft, to ensure that IPR has been disclosed in > > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > > more details). > > > > ==> *If* you are listed as a document author or contributor please > > respond to this email and indicate whether or not you are aware of any > > relevant IPR. > > > > The draft will not be adopted until a response has been received from > > each author and contributor. > > > > If you are not listed as an author or contributor, then please > > explicitly respond only if you are aware of any IPR that has not yet > > been disclosed in conformance with IETF rules. > > > > Thank you, > > > > Martin & Thomas > > bess chairs > > > > [1] > > https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________ > ____________________________________________________________ > > 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
