Paul, all,

>   The can-suppress tag itself is an Extended Communities Attribute
>   [RFC4360] to be assigned by IANA

It seems like you only need a single community value for tagging a route as 
"can-suppress". But in the draft, it seems like your are requesting the IANA to 
allocate a whole extended community type which is equivalent to 2^48 or 2^56 
values depending on the type being extended or regular. 

If you indeed need a single value, one option would be to take one from the 
pool of Assigned extended communities which is defined in 
draft-ietf-idr-reserved-extended-communities-00.


> 3.  IANA Considerations
>   IANA must assign type values for the Extended Communities Attributes
>   that convey the tags.

IMO it would help readers if you could state the name of the IANA registry. Cf 
ยง 5.1 of RFC 5226 (Guidelines for Writing an IANA Considerations Section in 
RFCs).
For example, assuming that you take a value from 
draft-ietf-idr-reserved-extended-communities draft could states:

3.  IANA Considerations

IANA is requested to assign, from the registry "BGP Reserved non-transitive 
extended communities", a value TBD for
   "VA can suppress":

 Registry Name: BGP Reserved non-transitive extended communities

    Name                                               Type Value
    ----                                               ----------
    VA can suppress                                    TBD



Best regards,
Bruno


> -----Original Message-----
> From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf Of 
> George, Wes E [NTK]
> Sent: Thursday, March 17, 2011 3:29 PM
> To: grow@ietf.org
> Subject: Re: [GROW] I-D Action:draft-ietf-grow-va-auto-03.txt
> 
> Reviewed this draft as well...
> 
> See also previous comments about Normative language
> 
> Regarding the draft itself, the only specific comment I might offer is that 
> you should probably
> specify in the beginning of section 2 when you first mention tagging routes 
> with a community that this
> community is NON-TRANSITIVE. When I read this, I started thinking about many 
> security concerns if this
> was not required to be a non-transitive community, only to find that it was 
> covered on the following
> page.
> 
> Wes George
> 
> -----Original Message-----
> From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Tuesday, February 22, 2011 8:00 AM
> To: i-d-annou...@ietf.org
> Cc: grow@ietf.org
> Subject: [GROW] I-D Action:draft-ietf-grow-va-auto-03.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Global Routing Operations Working Group of 
> the IETF.
> 
> 
>       Title           : Auto-Configuration in Virtual Aggregation
>       Author(s)       : P. Francis, et al.
>       Filename        : draft-ietf-grow-va-auto-03.txt
>       Pages           : 6
>       Date            : 2011-02-22
> 
> Virtual Aggregation as specified in [I-D.ietf-grow-va] requires configuration 
> of a static "VP-List" on
> all routers.  The VP-List allows routers to know which prefixes may or may 
> not be FIB- installed.
> This draft specified an optional method of determining this that requires far 
> less configuration.
> Specifically, it requires the configuration of a "VP-Range" in ASBRs 
> connected to transit and peer
> ISPs.  An Extended Communities Attribute is used to convey to other routers 
> that a given route can be
> FIB-suppressed.  This draft has no changes from the 02 draft.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-grow-va-auto-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically
> retrieve the ASCII version of the Internet-Draft.
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Reply via email to