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

From: <[email-masked]>
Date: Mon, 5 Oct 2015 09:28:30 +0200

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

[email-masked] :
> 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.

---

From: Ravi Singh <[email-masked]>
Date: Mon, 26 Oct 2015 19:28:40 +0000

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: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 5, 2015 12:29 AM
> To: [email-masked]; [email-masked]; Ravi
> Singh <[email-masked]>; Kireeti Kompella <[email-masked]>;
> [email-masked]
> Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags
> 
> 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.
> 
> > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
> > more details).
> >
> > [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.