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

Samita Chakrabarti wrote:
> 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.

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

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

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.

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

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

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