Subject: [Idr] comments on draft-chakrabarti-idr-rfc4893-mod-00.txt

From: Enke Chen <[email-masked]>
Date: Sat, 01 Mar 2008 21:30:53 -0800

Hi, folks:

I am posting my comments to the mailing list as I will not be at the 
upcoming
IETF meeting.

-) On Issue - 1

   IMO RFC4893 is pretty clear in stating that the Capability "carries 
the 4-octet
   Autonomous System number of the speaker in the Capability Value 
field". What
   else needs to be said?

-) On Issue - 2:

   The issues with having islands of the same AS number are well understood.
   Please see "RFC 2270: Using a Dedicated AS for Sites Homed to a 
Single Provider".

   We could add the reference when there is ever sufficient reason to 
update the document
   in the future.

-) On Issue - 3:

    The mechanism described in RFC 4893 is designed to avoid the need for a
    second transition for removing one of the attributes from the global 
routing
    system.

    The proposal in Sect. 6.1 is backwards, and would require exactly 
the second
    transition that we have worked very hard to avoid. The proposal is 
also not
    realistic as there is simply no easy way to know when the transition is
    "complete".

-) On Issue - 4:

    The reservation of AS_TRANS is relatively new. There are tons of old 
speakers in
    the field that would happily peer using the value if so configured. 
We can not
    mandate what an old speaker should or should not do as they are 
already there
    in the field :-)

    Also note that AS_TRANS is not the only reserved AS number.

    It is not clear if there is any practical value for introducing the 
notification.

Thanks.   -- Enke

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

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 4 Mar 2008 18:21:02 -0800

Hi Enke,

Thanks for your input. Please see my responses below.

>-----Original Message-----

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Enke

>Chen

>Sent: Saturday, March 01, 2008 9:31 PM

>To: idr

>Subject: [Idr] comments on draft-chakrabarti-idr-rfc4893-mod-00.txt

>   else needs to be said?

[SC>]  The issue-1 describes the need for clarification for implementation
on OPEN message processing when AS number is present in both capability
message and in "MY AS Number" fields. 

IMO, The document should clarify that AS Number present in Capability
message is used for the AS number and "My AS number" field is ignored. From
RFC 4893, it is assumed that nodes with 4byte-mappable 2-byte AS number can
advertise capability (AS4_PATH) as well as nodes with unmappable 4-byte AS
numbers. In case of un-mappable 4-byte AS numbers,the "My AS number" field
is AS_TRANS.

>   in the future.

[SC>]  Yes. It should be updated. IMHO, it might be a good idea to clarify
and update the document now before the deployment starts and face
interoperability issues. Are there many implementations in AS4_PATH that
have been interop tested ?

>    "complete".

[SC>] I don't think RFC 4893 can either tell if the transition is complete
or not by looking at the AS_PATH, since AS_PATH will always contain 4-byte
ASes between two NEW BGP speakers. At the border NEW BGP speaker, it gets
the AS_PATH with 2-byte ASes from the OLD BGP speaker, but there is no way
to know how many ASes are new by looking at the AS_PATH because some
speakers on the path may be 4-byte capable but they have a 2-byte mappable
AS number.

[SC>] Here is a brief analysis:

RFC 4893 style:

 Pro: A new BGP speaker can dynamically convert 2-byte AS number to 4-byte
AS-number in AS_PATH at the boundary.

Con: This requires extra processing of AS_PATH, AS_AGGREGATE conversion when
there is a OLD BGP peer on one side and a NEW BGP peer on the other side.
4-byte AS number migration will take time, thus during the long period of
transition, the border New BGP speaker will have to do this extra
processing. A new BGP speaker sometimes will process 4byte AS number in
AS_PATH and sometimes 2-bytes depending on whether it is coming from a NEW
speaker or OLD speaker. This overloading of AS_PATH usage can be
error-prone.

Proposed style in draft-chakrabarti-idr-rfc4893-mod-00.txt:

Pro: A NEW BGP speaker with 4-byte AS number always includes AS4_PATH

   attribute containing the extended 4-byte AS number.  If the AS number

   is 2-byte mappable, then it adds the corresponding 2-byte mapped AS

   number in the AS_PATH attribute, otherwise it uses AS_TRANS as the AS

   number in the corresponding AS_PATH attribute.  Thus the NEW BGP

   speaker will always have AS4_PATH and a corresponding AS_PATH

   attribute.  No conversion is needed at the transition boundary. Both
AS_PATH and AS4_PATH will co-exist during the transition period.

   When transition is over, a BGP speaker can use AS4_PATH only. It is a
simple concept and no overloading.

Con: Looking at AS_PATH or AS4_PATH info, one can not tell if the transition
has already happened in the Internet. But how important is it to know this
way? Was this a design goal ?

[SC>] I talked with a few people at NANOG who experienced that AS_TRANS
value was used often as AS number in the current BGP deployment. We can not
expect that every operator or administrator is fully aware of reserved
AS_TRANS value for this special purpose. Thus the notification message from
NEW BGP speaker to OLD BGP speaker who uses AS_TRANS value as "My AS number"
field in the OPEN message is very helpful during transition.

[SC>] besides, the transition section of RFC4893 should also mention the
order of AS number transition of PE/CE routers.Some folks think that PE
routers should be transitioned first (if not at the same time) in order to
take care of AS override function at the egress path. [ it is not part of my
draft yet ]

Regards,

-Samita

---

From: Enke Chen <[email-masked]>
Date: Tue, 04 Mar 2008 18:58:31 -0800

Hi, Samita:

Please see my comments inlined.

Samita Chakrabarti wrote:
> */ [SC>] The issue-1 describes the need for clarification for 
> implementation on OPEN message processing when AS number is present in 
> both capability message and in “MY AS Number” fields./*
>

The text in the document is very specific and clear.

> */ /*
>
> */ IMO, The document should clarify that AS Number present in 
> Capability message is used for the AS number and “My AS number” field 
> is ignored. From RFC 4893, it is assumed that nodes with 
> 4byte-mappable 2-byte AS number can advertise capability (AS4_PATH) as 
> well as nodes with unmappable 4-byte AS numbers. In case of 
> un-mappable 4-byte AS numbers,the “My AS number” field is AS_TRANS./*
>

Again, the document is clear about using AS_TRANS in the "My AS number" 
field:

   To represent 4-octet AS numbers (which are not mapped from 2-octets)
   as 2-octet AS numbers in the AS path information encoded with 2-octet
   AS numbers, this document reserves a 2-octet AS number.  We denote
   this special AS number as AS_TRANS for ease of description in the
   rest of this specification.  This AS number is also placed in the "My
   Autonomous System" field of the OPEN message originated by a NEW BGP
   speaker, if the speaker does not have a (globally unique) 2-octet AS
   number.

> */ /*
> */ /*
> */ [SC>] Yes. It should be updated. IMHO, it might be a good idea to 
> clarify and update the document now before the deployment starts and 
> face interoperability issues. Are there many implementations in 
> AS4_PATH that have been interop tested ?/*
>

Just FYI - there have been multiple implementations and deployments 
since 2004.

In terms of transition, please see Section 6. It assumes a reasonable 
way of transition:

   To simplify transition, this document assumes that an Autonomous
   System could start using a 4-octet AS number only after all the BGP
   speakers within that Autonomous System have been upgraded to support
   4-octet AS numbers.

> */ /*
> */ [SC>] I don’t think RFC 4893 can either tell if the transition is 
> complete or not by looking at the AS_PATH, since AS_PATH will always 
> contain 4-byte ASes between two NEW BGP speakers. At the border NEW 
> BGP speaker, it gets the AS_PATH with 2-byte ASes from the OLD BGP 
> speaker, but there is no way to know how many ASes are new by looking 
> at the AS_PATH because some speakers on the path may be 4-byte capable 
> but they have a 2-byte mappable AS number. /*
>
> >
>
> */ [SC>] Here is a brief analysis: /*
>
> */ /*
>
> */ RFC 4893 style: /*
>
> */ Pro: A new BGP speaker can dynamically convert 2-byte AS number to 
> 4-byte AS-number in AS_PATH at the boundary. /*
>
> */ /*
>
> */ Con: This requires extra processing of AS_PATH, AS_AGGREGATE 
> conversion when there is a OLD BGP peer on one side and a NEW BGP peer 
> on the other side. 4-byte AS number migration will take time, thus 
> during the long period of transition, the border New BGP speaker will 
> have to do this extra processing. A new BGP speaker sometimes will 
> process 4byte AS number in AS_PATH and sometimes 2-bytes depending on 
> whether it is coming from a NEW speaker or OLD speaker. This 
> overloading of AS_PATH usage can be error-prone. /*
>
> */ /*
>
> */ Proposed style in draft-chakrabarti-idr-rfc4893-mod-00.txt: /*
>
> */ Pro: /* A NEW BGP speaker with 4-byte AS number always includes 
> AS4_PATH
>
> */ /*
> */ Con: Looking at AS_PATH or AS4_PATH info, one can not tell if the 
> transition has already happened in the Internet. But how important is 
> it to know this way? Was this a design goal ? /*
>
>

This is a moot point at this time. After years of implementation and 
deployment, there can not be any change to the update generation. 
Besides what you proposed is something that was discussed and not 
pursued due to the major flaw I pointed out.

> */ [SC>] I talked with a few people at NANOG who experienced that 
> AS_TRANS value was used often as AS number in the current BGP 
> deployment. We can not expect that every operator or administrator is 
> fully aware of reserved AS_TRANS value for this special purpose. Thus 
> the notification message from NEW BGP speaker to OLD BGP speaker who 
> uses AS_TRANS value as “My AS number” field in the OPEN message is 
> very helpful during transition./*
>

Sorry to say that you might be misinformed of the use of AS 23456. In 
the public internet, one must use an AS number allocated by IANA. 
Otherwise there are consequences, including partial connectivities ....

The allocation and management of AS numbers are outside the scope of the 
document.

> */ /*
>
> */ /*
>
> */ [SC>] besides, the transition section of RFC4893 should also 
> mention the order of AS number transition of PE/CE routers.Some folks 
> think that PE routers should be transitioned first (if not at the same 
> time) in order to take care of AS override function at the egress 
> path. [ it is not part of my draft yet ]/*
>

Please see Section 6 (Transition) of the document. The document assumes 
(probably should recommends) that the provider networks are upgraded 
first before connecting non-mappable 4byte AS peers.

Regards, -- Enke

> */ /*
> */
> /*

---

From: Geoff Huston <[email-masked]>
Date: Wed, 05 Mar 2008 16:09:00 +1100

>>    second transition for removing one of the attributes from the global routing
>>    system.
>> 
>>    The proposal in Sect. 6.1 is backwards, and would require exactly the second
>>    transition that we have worked very hard to avoid. The proposal is also not

...

> simple concept and no overloading.

But there is no way for any individual BGP speak to know when transition 
is "over". I have to agree with Enke in observing that the proposal is 
indeed backwards.

> */[SC>] I talked with a few people at NANOG who experienced that 
> fully aware of reserved AS_TRANS value for this special purpose.

I'm sorry, but this is a specious line of reasoning.

Overall I see noting of use in this draft to warrant modification of RFC4893

   Geoff

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 5 Mar 2008 16:53:53 -0800

Hi Enke,

Below is my response in-line. 

>> both capability message and in "MY AS Number" fields./*
>>
>
[SC>] 
         It is specific about putting AS_TRANS in "My ASN" field when 4-byte
unmappable AS number is present.  But I am talking about processing OPEN on
receive side. Where is the text on that in RFC 4893?

>> Capability message is used for the AS number and "My AS number" field
>> un-mappable 4-byte AS numbers,the "My AS number" field is AS_TRANS./*
>>
>
[SC>]   This talks about send side. But, I am talking about text on receipt.

>Just FYI - there have been multiple implementations and deployments

[SC>] Any pointers on deployment?

>   speakers within that Autonomous System have been upgraded to support
[SC>] 
       Yes. I saw that.  
>pursued due to the major flaw I pointed out.
[SC>]
       If the idea on draft-chakrabarti was discussed before and not
adopted, then I'll not push this again. But the current solution has
weaknesses too that I pointed out in my last email.

>> uses AS_TRANS value as "My AS number" field in the OPEN message is
[SC>] 
[SC>]  I am well aware of IANA allocated AS number usage. That's not the
point.

>Otherwise there are consequences, including partial connectivities ....
[SC>] 
[SC>]  I agree. That's why a robust protocol takes care of sending some
error messages in some situations.

>first before connecting non-mappable 4byte AS peers.

[SC>]  I cannot see any specific words on 'provider networks' in section 6.

Please note that I am not trying to find flaws in RFC 4893, but requesting
some clarification on an important document that will be used for AS 4byte
transition. Clarity in the specification saves many interop issues and bugs
in the implementation, especially when something goes wrong in the Internet
domain routing, it can cause potential outage in the service. That's all.

Thanks,
-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 5 Mar 2008 17:11:46 -0800

Hi Geoff,

>is "over". I have to agree with Enke in observing that the proposal is
[SC>]  I did not mean that a BGP speaker would know when the transition is
over. I mentioned that transition period would be long. During that period
both AS_PATH and AS4_PATH will exist and the transition border NEW BGP
speaker does not need to do 2byte<->4byte AS_PATH, AS_AGGREGATOR conversion.

But, Enke mentions that similar proposal was discussed before and not
adopted. In that case I'll not push for this particular proposal. But it is
true that RFC 4893 is overloading AS_PATH sometimes with 2byte and sometimes
with 4bytes values, the NEW speaker will have to carefully take care of this
situation. It could lead into error-prone implementations.

>Overall I see noting of use in this draft to warrant modification of

[SC>] What is the objection against introducing a notification message to
the OLD BGP speaker from a NEW BGP speaker when it receives AS_TRANS in OPEN
message without AS4 capability?  This is quite useful for transition.

Regards,
-Samita

---

From: Geoff Huston <[email-masked]>
Date: Thu, 06 Mar 2008 14:17:37 +1100

> speaker does not need to do 2byte<->4byte AS_PATH, AS_AGGREGATOR conversion.

would you care to quantify the overhead of any such conversion?

average AS path length = 3.5

Number of updates per second appears to avers around 3 to 4

I'm sorry but I simply can't see what you think you are saving here

> situation. It could lead into error-prone implementations.

Yes, this was discussed about 3 years ago as well that the AS Path does 
not implicitly say whether the elements within the path are 2 or 4 
bytes. The consensus outcome of the WG was to run with what is in 
RFC4893. I think you you want to dredge over this ground again you are 
going to have to come up with hard facts, rather than another rerun of 
supposition and opinion of what "could" happen.

> message without AS4 capability?  This is quite useful for transition.

Lets see now what you are saying:

I configure to peer with AS 1. In the session the peer sends me an open 
message with a My AS number of 23456 without the capability to do 32 bit 
AS numbers - i.e. my peer is saying that it really is AS 23456. I 
terminate the session and spit out the diag that this is not the 
neighbor I expect to talk to.

Now the only way this will work is that I configure AS 23456 as my 
neighbor and you assert that you are AS23456. Fine.

Why would this happen ?

a) I am an OLD speaker and you have a non-mappable 32 bit AS number and 
you are a NEW BGP speaker. Well in this case this is precisely what is 
MEANT to happen

b) You and I agree that you really want to be AS23456. Well aside from 
the observation that you and I are demonstrating some level of ignorance 
about Standards and the IANA registry, no actual harm is being done.

So what is the problem you think that you are trying to solve here?

Hint: the AS Path is strictly speaking a loop detection mechanism and a 
comparison mechanism.

In what way would either loop detection or path comparison be impaired 
in the latter case?

Again, could we move away form the suppositions here and get to the hard 
facts?

regards,

      Geoff

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 7 Mar 2008 18:53:04 -0800

Please  see below in-line.

>Number of updates per second appears to avers around 3 to 4
[SC>] 
[SC>]  If there is 50+ peering connection then ~200 updates/sec for the
control-plane traffic. But one can argue that this is not worth worrying
about.

>I'm sorry but I simply can't see what you think you are saving here

[SC>]  My concern was more on overloading the AS_PATH data sometimes with
2-bytes and sometimes with 4-bytes values; it is error-prone from
programming point of view. 

But as I noted below that I understand the case is closed now. No point
arguing now.

>supposition and opinion of what "could" happen.
<snip>

>about Standards and the IANA registry, no actual harm is being done.
[SC>]  The ignorance of standards and specification in the field is the real
concern - I am not trying to address any algorithm issue here.

[SC>] 

[SC>] Human error or inconsistency of the implementation due to lack of
clarity in the specification - is the problem I am trying to address here.

Assuming your example, above:

  R1> router bgp 77777
    Router> neighbor 3.3.3.3 remote-as 23456  <---- The correct new BGP
implementation should not allow this command to succeed. But it is possible
because the RFC explicitly does not prohibit that, as you mentioned.

On R2> router bgp 23456  [ OLD BGP and they have been doing this incorrectly
due to ignorance ]

OLD BGP sends OPEN message with My ASN = 23456, but there is no AS4
capability.
At this point, the NEW BGP should reject the OPEN and does not peer.
RFC4271 provides Notification type 2 subtype 2 (bad AS); if new BGP
implementation could use that NOTIFICATION before closing TCP, the debug
info could help the poor IT person who does not understand the details we
discuss here in IETF.

Here is a reference based on some real experience from the field about
common mistakes in peering configuration; it might look silly but it can
save customer calls($$) if the debug message shows some hint.
http://www.nanog.org/mtg-0802/presentations/PSmith_BGP.pdf - checkout slide
30

Thanks,
-Samita