I-D Action:draft-ietf-idr-rfc4893bis-01.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 Working Group of the IETF.

	Title           : BGP Support for Four-octet AS Number Space
	Author(s)       : Q. Vohra, E. Chen
	Filename        : draft-ietf-idr-rfc4893bis-01.txt
	Pages           : 11
	Date            : 2009-10-02

Currently the Autonomous System (AS) number is encoded as a two-octet
entity in BGP. This document describes extensions to BGP to carry the
Autonomous System number as a four-octet entity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-01.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.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

I-D Action:draft-ietf-idr-aigp-01.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 Working Group of the IETF.

	Title           : The Accumulated IGP Metric Attribute for BGP
	Author(s)       : R. Fernando, et al.
	Filename        : draft-ietf-idr-aigp-01.txt
	Pages           : 13
	Date            : 2009-10-07

Routing protocols that have been designed to run within a single
administrative domain ("IGPs") generally do so by assigning a metric
to each link, and then choosing as the installed path between two
nodes the path for which the total distance (sum of the metric of
each link along the path) is minimized.  BGP, designed to provide
routing over a large number of independent administrative domains
("autonomous systems"), does not make its path selection decisions
through the use of a metric.  It is generally recognized that any
attempt to do so would incur significant scalability problems, as
well as inter-administration coordination problems.  However, there
are deployments in which a single administration runs several
contiguous BGP networks.  In such cases, it can be desirable, within
that single administrative domain, for BGP to select paths based on a
metric, just as an IGP would do.  The purpose of this document is to
provide a specification for doing so.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-aigp-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Question about RFC4893

Greetings,

I find myself in the process of updating one of our BGP
data-collectors to support 4-octet ASNs. I did my best to follow
RFC-4893, however I have a nagging feeling that I don't understand
one element. I hope you folks can point me in the right direction here.

The language in question is in section 4.2.3. The passages of
particular concern to me are:

Under certain conditions, it may not be possible to reconstruct the
entire AS path information from the AS_PATH and the AS4_PATH
attributes of a route.  This occurs when two or more routes that
carry the AS4_PATH attribute are aggregated by an OLD BGP speaker,
and the AS4_PATH attribute of at least one of these routes carries
at least one 4-octet AS number (as oppose to a 2-octet AS number
that is encoded in 4 octets).  Depending on the implementation,
either the AS4_PATH attribute would be lost during route
aggregation, or both the AS_PATH attribute and the AS4_PATH
attribute would contain valid, partial information that cannot be
combined seamlessly, resulting in incomplete AS path information in
these cases.

and

In order to construct the AS path information, it would be necessary
to first calculate the number of AS numbers in the AS_PATH and
AS4_PATH attributes using the method specified in Section 9.1.2.2
[BGP] and [RFC3065] for route selection. If the number of AS numbers
in the AS_PATH attribute is less than the number of AS numbers in

Re: Question about RFC4893

Ben,

1) RFC 4893 has been revised by the following document:

     http://www.ietf.org/id/draft-ietf-idr-rfc4893bis-01.txt

2) Sect. 4.2.3 presents a complete, and precise algorithm for 
constructing the as-path:

----------------------------------

   A NEW BGP speaker should also be prepared to receive the
   AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an
   OLD BGP speaker.  When both the attributes are received, if the AS
   number in the AGGREGATOR attribute is not AS_TRANS, then:

      -  the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL
         be ignored,

      -  the AGGREGATOR attribute SHALL be taken as the information
         about the aggregating node, and

      -  the AS_PATH attribute SHALL be taken as the AS path
         information.

   Otherwise,

      -  the AGGREGATOR attribute SHALL be ignored,

      -  the AS4_AGGREGATOR attribute SHALL be taken as the information

Re: Question about RFC4893

Ben,

A correction here:   RFC 4893 is being revised (instead of "has been 
revised") by rfc4893bis.

Thanks to an IDR member who pointed out the difference.

-- Enke

Enke Chen wrote:
> Ben,
>
> 1) RFC 4893 has been revised by the following document:
>
>     http://www.ietf.org/id/draft-ietf-idr-rfc4893bis-01.txt
>
> 2) Sect. 4.2.3 presents a complete, and precise algorithm for 
> constructing the as-path:
>
> ----------------------------------
>
>   A NEW BGP speaker should also be prepared to receive the
>   AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an
>   OLD BGP speaker.  When both the attributes are received, if the AS
>   number in the AGGREGATOR attribute is not AS_TRANS, then:
>
>      -  the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL
>         be ignored,
>
>      -  the AGGREGATOR attribute SHALL be taken as the information

Re: Question about RFC4893

Hi Ben,

Please see below:

> If the number of AS numbers in the AS_PATH attribute is larger than or
equal
> to the number of AS numbers in the AS4_PATH attribute, then the AS path
> information SHALL be constructed by taking as many AS numbers and path
> segments as necessary from the leading part of the AS_PATH attribute, and
> then prepending them to the AS4_PATH attribute so that the AS path
> information has an identical number of AS numbers as the AS_PATH
attribute.
> 
> 
> 
> Forgive me, but this all sounds like an awful lot of hand-waving to me.
Has
> anything been done since this RFC was published to better describe in a
more
> formal way the procedure a BGP speaker should follow to re-construct an
> accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based on this
> description I can see more than one way to implement this. I would like to
> do so correctly, but I need to know what is correct first.
> 
> Thanks
> Ben
> 
[SC>] 

Re: Question about RFC4893

Samita:

We can argue about the presentation style and other portions in 
RFC4893.  However,  IMO the specific
merge algorithm is complete, and precise,  as I pointed out to Ben.

Please see my comments inlined.

Samita Chakrabarti wrote:
> Hi Ben,
>
> Please see below:
>
>   
>> If the number of AS numbers in the AS_PATH attribute is larger than or
>>     
> equal
>   
>> to the number of AS numbers in the AS4_PATH attribute, then the AS path
>> information SHALL be constructed by taking as many AS numbers and path
>> segments as necessary from the leading part of the AS_PATH attribute, and
>> then prepending them to the AS4_PATH attribute so that the AS path
>> information has an identical number of AS numbers as the AS_PATH
>>     
> attribute.
>   
>>
>> Forgive me, but this all sounds like an awful lot of hand-waving to me.
>>     
> Has

Re: Question about RFC4893

Hi Enke,

I am OK with the current text in rfc4893-bis that you already pointed out.

I provided some additional examples for clarification and for the purpose of
discussion.

Cheers,
-Samita
> -----Original Message-----
> From: Enke Chen [mailto:enkechen <at> cisco.com]
> Sent: Friday, October 09, 2009 11:58 AM
> To: Samita Chakrabarti
> Cc: ben_april <at> trendmicro.com; idr <at> ietf.org; Enke Chen
> Subject: Re: [Idr] Question about RFC4893
> 
> Samita:
> 
> We can argue about the presentation style and other portions in RFC4893.
> However,  IMO the specific merge algorithm is complete, and precise,  as I
> pointed out to Ben.
> 
> Please see my comments inlined.
> 
> Samita Chakrabarti wrote:
> > Hi Ben,
> >
> > Please see below:
> >
> >

Re: Question about RFC4893

BTW,  based on the on-line IETF track tool, there has been no change in 
the merge algorithm (Sect 4.2.3) from RFC 4893 to rfc4893bis-00.txt and 
to rfc4893bis-01.txt:

          
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr-rfc4893bis-00.txt

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr-rfc4893bis-01.txt

Regards,   -- Enke

Enke Chen wrote:
> Samita:
>
> We can argue about the presentation style and other portions in 
> RFC4893.  However,  IMO the specific
> merge algorithm is complete, and precise,  as I pointed out to Ben.
>
> Please see my comments inlined.
>
> Samita Chakrabarti wrote:
>> Hi Ben,
>>
>> Please see below:
>>
>>  
>>> If the number of AS numbers in the AS_PATH attribute is larger than or
>>>     
>> equal
>>  

Re: Question about RFC4893

Hi Enke,

You are right in pointing out that there is no change from RFC4893 merging
text into the bis versions . I replied too fast. It's been a long time since
we implemented this, but I remember it was not clear at that time and we had
to do some interpretation of the text in RFC.

Below, you have discussed the merged AS-PATH examples with the sample
scenarios I provided.
Do you think you can include some of those examples in the text for
clarification? That might be helpful for the future implementations for
clarity. Just a suggestion...

Thanks,
-Samita

> -----Original Message-----
> From: Enke Chen [mailto:enkechen <at> cisco.com]
> Sent: Friday, October 09, 2009 12:11 PM
> To: Samita Chakrabarti
> Cc: ben_april <at> trendmicro.com; idr <at> ietf.org; Enke Chen
> Subject: Re: [Idr] Question about RFC4893
> 
> BTW,  based on the on-line IETF track tool, there has been no change in
the
> merge algorithm (Sect 4.2.3) from RFC 4893 to rfc4893bis-00.txt and to
> rfc4893bis-01.txt:
> 
> 
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr-