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

Hi Geoff,

>>
>>    When transition is over, a BGP speaker can use AS4_PATH only. It is a
>> 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 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.

>>>-) On Issue - 4:
>>
>>>
>
>> */[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.
>
>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

[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

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