Subject: Re: [Idr] Re: 4-Byte As Number soon to come?

From: Curtis Villamizar <[email-masked]>
Date: Thu, 01 Sep 2005 15:01:50 -0400

In message <6.2.1.2.0.20050831230250.02ee26b0@localhost>
"Joel M. Halpern" writes:
>  
> Given that path prepending is the primary (arguably the only) way for an 
> advertiser to express provider preference in a way visible to information 
> receivers, it seems that AS Path length is still our primary knob.
>  
> This would suggest that having routers along a path change the AS Path 
> length of advertisements they have (potentially shortening the length) 
> would be a very bad thing.
>  
> It was precisely to avoid such misleading effects that we introduced the 
> series of AS Sets.
>  
> Yours,
> Joel M. Halpern

Joel,

If memory serves me, AS-SETs were introduced for aggregation and AS
Path length wasn't in use yet.  Cisco put AS Path length into their
implementation after rfc1771 and it became widely implemented even
though it differred from the spec.  So we fixed the spec to match
running code, operational experience, and widespread deployment.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Glen Kent <[email-masked]>
Date: Wed, 7 Sep 2005 22:55:45 +0530

> running code, operational experience, and widespread deployment.
Curtis,
 What exactly was fixed in the spec to match the "running code, operational 
experience, and widespread deployment" ?
Is it, allowing the BGP speaker to collapse multiple AS_SETs, or is it 
counting multiple AS_SETs as 1? I dont think there is any running code that 
does any of the above. 
 Are you sure we're not trying to "fix" something that aint yet broken?
 Glen
_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 09 Sep 2005 12:43:56 -0400

In message <[email-masked]>
Glen Kent writes:
>  What exactly was fixed in the spec to match the "running code, operational>  
> counting multiple AS_SETs as 1? I dont think there is any running code that>  
> does any of the above. 

In "9.1.2.2 Breaking Ties (Phase 2)" the following was added.

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set.

RFC 1771 does not have this tie breaking rule.  The rule did not exist
at all therefore it also didn't say how to count an AS_SET.

There has always been clear concensus that we add this to match
reality.

Counting all the AS in an AS_SET rather than just counting the set has
always been considered to be "a bug" in implementations that do that.

Curtis

---

From: Glen Kent <[email-masked]>
Date: Sat, 10 Sep 2005 08:12:33 +0530

Curtis wrote:

> at all therefore it also didn't say how to count an AS_SET.

 Yes.

> always been considered to be "a bug" in implementations that do that.

 Isnt this *exactly* what *everybody* in this list is saying? Particularly 
the author(s) to whom you replied?
 I am amused as well curious now. Which email in this *entire* thread makes 
you think that the author thinks otherwise?
 Which is why, when you merge the SETs, you _can_ break what other people 
think from the path length. Decreasing the path length midway (by merging 
AS_SETs) IMO is a bad practise and nobody has any business doing this.
 And note, before anybody sparks a reply, I am not talking about a router 
thats doing aggregation, because that router is essentially originating a 
new prefix. I (like others) am talking of router that sits in the middle and 
suddenly decides to merge all the SETs to form one big SET before passing on 
the routes to its peer.
 Thanks
 -- 
Glen
_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "john smith" <[email-masked]>
Date: Sat, 10 Sep 2005 11:09:52 +0000

>It was precisely to avoid such misleading effects that we introduced the 

then perhaps one of the authors would like to explain the arguments in this:

http://www.merit.edu/mail.archives/idr/2004-09/msg00023.html

:-)

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 10 Sep 2005 12:07:50 -0400

> http://www.merit.edu/mail.archives/idr/2004-09/msg00023.html

That message was about weights and local-pref.  It appears to have
nothing to do with AS Sets.  Is it possible you got the URL wrong?

Curtis

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Sep 2005 19:05:23 -0400

There are a set of decision items laid out in the I-D that will be the new 
BGP RFC.
These include, under certain circumstances, comparing the number of 
elements in the AS path.
If we had and were using the metric that was recently proposed, this would 
not be an issue.

Specifically, in section 9.1.2.2 if multiple routes have gotten this far 
then "Remove from consideration all routes which are not tied for having 
the smallest number of AS numbers present in the AS Path attributes.  Note 
that when counting this number, an AS_Set counts as 1, no matter how many 
ASs are in the set."

Given that the number of ASs (seqeunce elements or sets) can have a direct 
effect on the selection of routes, we don't want to break that criteria 
while allowing a router to use multiple routes.  And when such a router 
speaks to a non-ECMP router, we want the number of AS (as described above) 
to be the same as it would have had if ECMP had not been used.

Note that this text does not say to collapse adjacent AS Sets, but rather 
that each AS set counts as one AS for comparison purposes.

Yours,
Joel M. Halpern

At 04:49 PM 9/18/2005, john smith wrote:
>Yes possibly i did,
>
>i think it would help if someone could help clarify when exactly 
>local_pref came into the picture.
>
>I was wondering if the authors could help clarify the motivation of 
>retaining path length.
>
>
>>From: Curtis Villamizar <[email-masked]>
>>Reply-To: [email-masked]
>>To: "john smith" <[email-masked]>
>>CC: [email-masked], [email-masked]
>>Subject: Re: [Idr] Re: 4-Byte As Number soon to come? Date: Sat, 10 Sep 
>>2005 12:07:50 -0400
>>
>Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 18 Sep 2005 22:30:52 -0400

> local_pref came into the picture.

Day one.  local_pref appeared in the internet-draft that was the basis
for the first versions of BGP4 from Cisco deployed in late fall of
1993 and the gated version deployed in the NSFHET in 1994.  That
internet-draft predated rfc1771.  local_pref has always been in
rfc1771 as well.

> I was wondering if the authors could help clarify the motivation of

If what you mean by "retaining path length" means using AS path length
in the decision process, this was to match widespread implementation
and deployment.  But I already said that a few messages back on this
thread.

Curtis

---

From: Geoff Huston <[email-masked]>
Date: Tue, 20 Sep 2005 11:34:44 +1000

Hi,

At the last IDR working group meeting I took the action to complete
an implementation report on the 4-byte AS draft.  The attached
implementation report has been submitted as an internet draft
(to be published as draft-huston-idr-as4bytes-survey-00.txt)

My thanks to Bruno Rijsman, Enke Chen and Albert Tian for their
kind assistance in assembling this report.

regards,

   Geoff

----------------------------------------------------------------------------
4-Byte AS Implementation Report

September 2005

Abstract

   This document provides a survey of BGP-4 4-Byte AS Number support
   implementations.

1.  Survey Summary

   This document provides a survey of BGP-4 4-Byte AS Number Support
   [ID.4ByteAS] implementations.  After a brief summary, each response
   is listed.  The editor makes no claim as to the accuracy of the
   information provided.

2.  Summary Forms

2.1.  Juniper Networks

   Organization: Juniper Networks

   Person filling out this form:
      Bruno Rijsman <[email-masked]>

   Implementation:
      JUNOSe 4-1-0 and later

   Does the implementation include all parts of the specification:
      Yes

   Are there parts of the specification that are unclear where the
   implementor had to exercise some judgement that may impact
   interoperability?
      *  It isn't clear what to do if the information in the old as-path
         is inconsistent with the information in the new as-path.
      *  There some places where AS numbers are used where it wasn't
         clear how to deal with 4-octet as-numbers (e.g. extended
         communities).
      *  It isn't spelled out that this capability cannot be dynamically
         negotiated.

   Has there been any interoperability testing?
      Yes; no problems were discovered.

      1.  NEW / OLD ineroperability testing with:
             Juniper ERX (older version which does not support draft)
             Juniper M/T/J
             Cisco 7500

      2.  NEW / NEW interoperability testing with:
             Juniper M/T/J
             Redback SmartEdge

      3.  Most deployed Juniper ERX routers run code which supports
          4-octet AS-numbers (and the feature is enabled by default).
          This provides some confidence that the draft does not cause
          interoperability problems.  Note however that the NEW_AS_PATH
          attribute is not generated unless the AS-path contains at
          least one AS-number greater than 65535 which is -as far as we
          know- not yet the case in the Internet today.

   Has there been testing of the interface between this implementation
   and the 2-byte BGP implementation on the NEW (4-byte) to OLD (2byte)
   update path?
      Yes

   Has there been testing of the OLD (2-byte) to NEW (4-byte) path?
      Yes

   Have there been any issues noted with the mechanism to reconstruct
   the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS
   Path on an OLD -NEW BGP update session?
      It isn't clear what to do if the information in the old as-path is
      inconsistent with the information in the new as-path.

   Any other comments regarding the implementation
      Some older versions of Cisco IOS send an unsupported capability
      notification (instead of ignoring the capability) when they
      receive a capability advertisement which they don't recognize and
      which has non-empty data.  The 4-octet as-number capability is
      such a capability.  Our implementation recognizes this
      notification and stops automatically stops advertising the 4-octet
      as-numbers capability (and others) until the next hard clear on
      the BGP session.

2.2.  Redback

   Organization: Redback

   Person filling out this form:
      Albert Tian <[email-masked]>

   Does the implementation include all parts of the specification:
      Yes

   Are there parts of the specification that are unclear where the
   implementor had to exercise some judgement that may impact
   interoperability?
      No.

   Has there been any interoperability testing?
      Yes

   Has there been testing of the interface between this implementation
   and the 2-byte BGP implementation on the NEW (4-byte) to OLD (2byte)
   update path?
      Yes (Cisco: 2-byte; Redback: 4 byte).

   Has there been testing of the OLD (2-byte) to NEW (4-byte) path?
      Yes. (Cisco: 2-byte; Redback: 4-byte).

   Have there been any issues noted with the mechanism to reconstruct
   the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS
   Path on an OLD -NEW BGP update session?
      No

   Have there been any issues noted with the mechanism to reconstruct
   the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS
   Path on an OLD -> NEW BGP update session?
      No.

   Any other comments regarding the implementation
      No

References

   [ID.4ByteAS]
              Vohra, Q. and E. Chen, "BGP support for four-octet AS
              number space", Work in progress, Internet
              Draft: draft-ietf-idr-as4bytes-10.txt, July 2005.

Author

   Geoff Huston
   Asia Pacific Network Information Centre
   Email: [email-masked]
   URI:   http://www.apnic.net