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

On Tue, 11 Oct 2005, John Leslie wrote:

> Following this principle, I prefer to use the 2-octet-AS path info 
> I get from my OLD BGP peer unless I'm confident I can do better. 
> (Arguably, we'd be better off to ignore NEW_AS_PATH entirely, but 
> that would sentence folks with AS > 65535 to never detect their 
> loops.)
>
>  So while I agree we don't know which path is "wrong", we do know
> which one the peer we got it from will use.

The peer you got it from is OLD and is in the dark anyway wrt 4-byte 
ASNs. The 2-byte AS_PATH is therefore already incomplete and "wrong".

> Thus, we know which one is "better".

> I fail to see how discarding the UPDATE could be appropriate.

I disagree. Propogating known-inconsistent routes onward is asking 
for trouble during any transition period.

If there's an inconsistency between the two something has either gone 
badly wrong somewhere, or an OLD speaker in the path somewhere has 
decided to make major modifications to the 2-byte AS_PATH for reasons 
known only to itself (an attacker?), specifically modifying the 
portions that contained mapped-to-2byte ASNs, not realising it's 
destroying information it doesn't fully comprehend.

> I really don't see any way to "reconcile" the paths.

Sure there is, there has to be or this draft just can not work at 
all. And if the 2 paths are consistent (and there isn't a good reason 
for them not to be) then it's easy. ;)

>> Ah, indeed yes, that needs clarification too. If AGGREGATOR is /not/
>> AS_TRANS then indeed AGGREGATOR is the last aggregator, and
>> NEW_AGGREGATOR is just simply stale.
>
>   True.

The draft though says NEW_AGGREGATOR should always be used by a NEW 
speaker over AGGREGATOR. So that needs to be fixed in the draft too.

>   We'd be better advised to choose, IMHO.
>
>   And I'd advise choosing to "retrofit". We're going to be stuck 
> with a mixture of systems for many years into the future. 
> (Hopefully, systems nearest the backbone will become NEW BGP 
> quickly when ASNs greater than 65535 are allocated; but purchase 
> cycles will drag on in both directions. Near the edge, nothing 
> _has_to_ happen until you want to peer with an AS > 65535.)

It's the other way around more likely. The edges of the internet are 
more likely to go NEW first (new ASes, the ones which will get 4-byte 
ASNs first, tend to be leaf sites). Indeed the 'backbone' of the 
internet could stay OLD forever, with edge ASes NEW and it'd still 
work fine. If we presume new ASes with 4-byte ASNs get NEW equipment, 
then we can imagine various 'edges' of the internet will look like:

A-B---<rest of internet>
  /
C

If A, B and C are 4-byte, then it just works. To the 'core' of the 
internet, if still 2-byte, it just looks as if there's some new 
super-AS (AS_TRANS) slowly taking over all the new leaf ASes on the 
internet ;).

> Well, that's an open question: if indeed the draft says it MUST be 
> discarded and the NEW_AS_PATH patched in for the remainder, there 
> MIGHT be no reason to see it coming from a NEW BGP speaker to 
> another NEW BGP speaker.

>   But IMHO the draft does _not_ say that. Nor IMHO should it.

It doesn't say it, no. I suspect it should though, as seeing AS_TRANS 
in a 4-byte AS_PATH would be a strong indicator someone screwed up.

What good reason is there to /not/ mandate that AS_TRANS expressed 
4-byte ASN form is an error?

>   IMHO, the draft needs editing to clarify whether we're 
> retrofitting or tunneling. (I trust my recommendation between these 
> is clear.)

I'm not sure why it makes a difference :).

We're moving from 2 to 4 bytes for ASNs, retrofitting 4-bytes on the 
existing BGP protocol and providing for some form of tunneling of 
4-byte AS_PATH's through BGP speakers as a transitional mechanism.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
He who has but four and spends five has no need for a wallet.

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