Subject: Re: [GROW] I-D Action:draft-ietf-grow-va-auto-03.txt

From: "George, Wes E [NTK]" <[email-masked]>
Date: Thu, 17 Mar 2011 14:29:29 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, February 22, 2011 8:00 AM
To: [email-masked]
Cc: [email-masked]
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.

---

From: <[email-masked]>
Date: Mon, 21 Mar 2011 11:30:12 +0100

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of George, Wes E [NTK]
> Sent: Thursday, March 17, 2011 3:29 PM
> To: [email-masked]
> Subject: Re: [GROW] I-D Action:draft-ietf-grow-va-auto-03.txt
> 
> 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
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> This draft is a work item of the Global Routing Operations Working Group of the IETF.
> 
> 
> 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.
> 
> Below is the data which will enable a MIME compliant mail reader implementation to automatically
> retrieve the ASCII version of the Internet-Draft.