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

Hi Enke,

Below is my response in-line. 

>> >
>>
>> > 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./*
>>
>
>The text in the document is very specific and clear.
>
[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?

>> */ /*
>>
>> */ 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>]   This talks about send side. But, I am talking about text on receipt.

>> >
>>
>> >-) 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.
>>
>> */ [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.

[SC>] Any pointers on deployment?

>
>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>] 
       Yes. I saw that.  
>
>> */ /*
>> */ 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>]
       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.

>
>>
>> */ [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.
[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.

>
>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.
>

[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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr