Re: [mpls] [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03

Hi Keyur,

 > From: Keyur Patel [mailto:keyur@arrcus.com]  > Sent: Saturday, May 20, 2017 2:43 AM
> 
 > Support. However, It would be great if the attribute format adopts new attribute definition
 > of : https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-attribute-announcement/
 > 
 > This will help scope the attribute announcements.

Thanks for the support.

TL;DR: Interesting comment regarding draft-ietf-idr-bgp-attribute-announcement. But I feel that the comment is more related to draft-ietf-idr-bgp-attribute-announcement, and how we(IDR) can make it real.

A priori, to enforce the use of draft-ietf-idr-bgp-attribute-announcement for future BGP attributes, we need an RFC. But to get that RFC, IDR requests 2 implementations. Hence there is a need to implement it on a first attribute. 3 options:

a) pick a draft / attribute more or less randomly.
Pro: easy path for  -bgp-attribute-announcement
Con: typical reaction for the choose draft may be "why me?", "not in my backyard"

As a matter of fact ;-) I don't feel that draft-decraene-idr-next-hop-capability is the best choice given that the next-hop attribute is removed when the next-hop is changed, so typically will already not leave an AS/administrative domain. So there is less need for filtering capability on AS border. Plus bgp-attribute-announcement provides filtering capability on an attribute basis, why -next-hop-capability would better benefit from filtering on a capability basis.

May be the iOTC attribute would be a better fit, especially since it already needs to implement filtering on AS boundaries and may benefit from enhanced filtering capabilities. 

b) pick a dedicated attribute code, just to implement the general behavior.
Could even be a deprecated code point given that it won't be used in deployment.
Con: difficult to fund the implementation since the benefit is null in the short term.

c) split bgp-attribute-announcement into 2 drafts/phases:
- phase 1: define the new Extended Path Attribute Flags field (i.e. 4 null octets). With no flag  defined
- phase 2: defines the new flags.

Pro:
Phase 1 is very easy to implement for any new attribute. Hence high chance to get implementation --> RFC --> mandate this new format. Speaking for myself, I'm open to add this phase 1 in next-hop-capability (once this phase1 document is written, accepted as WG doc, preferably WGLC)
Phase 2 has more incentive to get implemented since the flags would be applicable to multiple attributes i.e. the benefit would be multiplied by N.

Best regards,
-- Bruno

 > Regards,
 > Keyur
 > 
 > On 5/19/17, 7:35 AM, "Idr on behalf of bruno.decraene@orange.com" <idr-
 > bounces@ietf.org on behalf of bruno.decraene@orange.com> wrote:
 > 
 >     Support as coauthor
 > 
 >      > -----Original Message-----
 >      > From: John G.Scudder [mailto:jgs@juniper.net]
 >      > Sent: Thursday, May 18, 2017 6:35 PM
 >      > To: idr wg
 >      > Cc: draft-decraene-idr-next-hop-capability@ietf.org; mpls@ietf.org
 >      > Subject: Working Group adoption call for draft-decraene-idr-next-hop-capability-03
 >      >
 >      > [resending, correcting draft@ietf address]
 >      >
 >      > Hi All,
 >      >
 >      > IDR working group adoption has been requested for draft-decraene-idr-next-hop-
 >      > capability-03. Please send your comments to the IDR mailing list before June 2, 2017.
 > Please
 >      > remember that we need affirmative support in order to adopt the draft, so don't be
 > shy.
 >      >
 >      > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-
 >      > capability/
 >      > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-
 > next-
 >      > hop-dependent-capabilities-00.pdf
 >      >
 >      > Since in part this draft specifies a replacement for the Entropy Label Capability
 > Attribute
 >      > (ELCA) that was defined by the MPLS WG in RFC 6790 and deprecated by RFC 7447, I
 > have
 >      > cc'd the MPLS WG mailing list. Since the proposed new attribute is a generic container
 > with
 >      > the ELCA replacement just the first application, the current draft is targeted to IDR and
 > not
 >      > MPLS (this was discussed during IETF-93).
 >      >
 >      > Thanks,
 >      >
 >      > --John
 > 
 > 
 > ______________________________________________________________________
 > ___________________________________________________
 > 
 >     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.
 > 
 >     _______________________________________________
 >     Idr mailing list
 >     Idr@ietf.org
 >     https://www.ietf.org/mailman/listinfo/idr
 > 

_________________________________________________________________________________________________________________________

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.