Re: [Idr] I-D Action: draft-ietf-idr-bgp-attribute-announcement-00.txt

In section 3, under the figure illustrating the bits, it says (R = MUST Be Zero).
This means that any future feature that wants to use the reserved bits will fail, because legacy speakers would change the new bits to zero.

The reserved bits in the original BGP path attribute flags are specified as "MUST Be Zero". This is why they could not be used for this new scoping functionality.

The new 4 byte extended path attribute flags should add a sentence to avoid the same fate of its reserved bits:

"The Reserved bits MUST be originated as zero. However, to support the future use of these bits, the Reserved bits MUST be propagated as received. Once any future feature makes use of a bit, it may change the rules of propagation of its bits."

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Friday, July 08, 2016 12:46 PM
> To: i-d-announce@ietf.org
> Cc: idr@ietf.org
> Subject: [Idr] I-D Action: draft-ietf-idr-bgp-attribute-announcement-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing of the IETF.
> 
>         Title           : Constrain Attribute announcement within BGP
>         Authors         : Keyur Patel
>                           James Uttaro
>                           Bruno Decraene
>                           Wim Henderickx
>                           Jeff Haas
> 	Filename        : draft-ietf-idr-bgp-attribute-announcement-00.txt
> 	Pages           : 9
> 	Date            : 2016-07-08
> 
> Abstract:
>    [RFC4271] defines four different categories of BGP Path attributes.
>    The different Path attribute categories can be identified by the
>    attribute flag values.  These flags help identify if an attribute is
>    optional or well-known, Transitive or non-Transitive, Partial, or of
>    an Extended length type.  BGP attribute announcement depends on
>    whether an attribute is a well-known or optional, and whether an
>    attribute is a transitive or non-transitive.  BGP implementations
>    MUST recognize all well-known attributes.  The well-known attributes
>    are always Transitive.  It is not required for BGP implementations to
>    recognise all the Optional attributes.  The Optional attributes could
>    be Transitive or Non-Transitive.  BGP implementations MUST store and
>    forward any Unknown Optional Transitive attributes and ignore and
>    drop any Unknown Optional Non-Transitive attributes.
> 
>    Currently, there is no way to confine the scope of Path attributes
>    within a given Autonomous System (AS) or a given BGP member-AS in
>    Confederation.  This draft defines attribute extensions that help
>    confine the scope of Optional attributes within a given AS or a given
>    BGP member-AS in Confederation
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-attribute-announcement/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-idr-bgp-attribute-announcement-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr