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

[Paul Jakma <[e-mail]>]

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

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

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? ;)

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

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.

> Yakov.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Thank goodness modern convenience is a thing of the remote future.
 		-- Pogo, by Walt Kelly

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