Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags

[Ravi Singh <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> Sent: Monday, October 5, 2015 12:29 AM
> To: [e-mail]; [e-mail]; Ravi
> Singh <[e-mail]>; Kireeti Kompella <[e-mail]>;
> [e-mail]
> 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
> 
> 
> [e-mail] :
> > 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.