Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt

[Enke Chen <[e-mail]>]

Hi, Paul:

Paul Jakma wrote:

> On Fri, 7 Oct 2005, Yakov Rekhter wrote:
>
>> Folks,
>>
>> This is to start the WG Last Call on advancing 
>> draft-ietf-idr-as4bytes-11.txt to a Proposed Standard. The 
>> implementation report is draft-huston-idr-as4bytes-survey-00.txt.
>
>
> 1. Surely the questions raised in the implementation report should
> first be at least examined, if not addressed? (concerns 5.2.3 at
> least, see 3.).

We did examine the questions raised:

* 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 is no good answer here - but will clarify on re-constructing the 
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).

Not a problem as the extended community spec has allocated type code for 
4-byte ASs.

* It isn't spelled out that this capability cannot be dynamically
negotiated.

Not a problem for the revised version of the dynamic capability - 
although there is no reason to make the capability dynamic in this case.

>
> 2. Section 5.3 should be deleted, I'm not sure how this draft could
> ever mandate behaviour for OLD speakers, when OLD specifically is
> defined to be those peers which do not implemented the extensions
> defined in the draft. ;)


Will delete the section.

>
> 3. NEW_AS_PATH parsing/actions are barely specified.
>
> Eg:
>
> NEW NEW NEW OLD OLD NEW
> AS256---AS200000---AS512---AS1024---AS2048---AS4096
>
> According to 5.2.2, AS512 should create an AS_PATH attribute for 
> AS1024 that preserves the path-length by representing each 4-byte ASN 
> with AS_TRANS, and should construct NEW_AS_PATH as per AS_PATH (the 
> AS_PATH as received previously presumably). So AS1024 would receive:
>
> AS_PATH: seq(512,AS_TRANS,256)
> NEW_AS_PATH: seq(200000,256)
>
> AS4096 would receive:
>
> AS_PATH: seq(2048,1024,512,AS_TRANS,256)
> NEW_AS_PATH: seq(200000,256)
>
> 5.2.3 states that:
>
> "<leading part of AS_PATH information> should be prepended to the 
> NEW_AS_PATH attribute to construct the exact AS path information."
>
> Where "leading part" are those ASN that are only 2-byte and OLD. But 
> we're not told how one should deduce where this leading part finishes. 
> The simplistic approach of "closest AS_TRANS marks end of leading 
> part", which is suggested by definition of "leading part" would give us:
>
> seq(2048,1024,512,200000,256)
>
> Which is the correct result, however the method is wrong. Imagine if 
> the 200000 and 256 are the other way around:
>
> AS_PATH: seq(2048,1024,512,256,AS_TRANS)
> NEW_AS_PATH: seq(256,200000)
>
> Using previous method would give:
>
> seq(2048,1024,512,256,256,200000)
>
> Which result is wrong :). Obviously, one should use the n #-of-ASNs in 
> the *NEW_AS_PATH* as the *trailing* part of the real AS_PATH 
> information and override the last n ASNs in the AS_PATH. So why 
> doesn't the draft state this? ;)


Will clarify on how to re-construct the as-path. Will send out the text 
when it is ready.

>
> I.e. The full process should preferably be *documented* in the draft, 
> but at a minimum this vague (if not slightly misleading) 'prepend 
> leading part of AS_PATH' language should be removed.
>
> Also, if a process to reconcile AS_PATH and NEW_AS_PATH is to be 
> described (I think it should ;) ), obvious questions arise, as one 
> responder to the implementation report hints at:
>
> a) Should/Must the "overriden" ASNs in the AS_PATH be reconciled
> against the NEW_AS_PATH ASNs which are replacing them?
>
> b) If so, what if they can /not/ be reconciled?
>
> 4. Some mention, surely, could be made of the issues protocol
> decoders will face, and of the ASN allocation strategy which could
> help remove this issue? (It has a cost of one additional reserved
> 2-byte ASN).


Not sure if this is necessary (based on the previous discussions).

>
> 5. 5.2.3 contains the following statement:
>
> "<the NEW_AS_PATH> attribute may not have been updated since the route 
> left the last NEW BGP speaker."
>
> Which raises the question of how exactly any speaker besides a NEW (or 
> NEW-compatible) speaker would modify NEW_AS_PATH? Indeed, NEW_AS_PATH 
> can /not/ propogate across NEW speakers. The last speaker to have 
> "modified" NEW_AS_PATH is, by the language of the draft, the NEW 
> speaker which formed it which must therefore be the last NEW speaker. 
> So the "may not" should read "will not" instead.


Will revised.

Thanks a lot!

-- Enke

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