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

   Paul and I have hashed out a few things privately. I'd like to
update folks on stuff I think we've agreed not to argue on the list:

Paul Jakma <paul@clubi.ie> wrote:
> On Tue, 11 Oct 2005, John Leslie wrote:
> 
>>
>> 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.

   I believe Paul is ready to humor me here.

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

   But not here. I promise not to argue "better".

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

   I can't say we're particularly close to agreement, but I have
agreed that discarding the NLRI in an UPDATE containing an AS_PATH
and a NEW_AS_PATH known to be inconsistent is a valid action.

   I believe that discarding such NLRIs _should_ be permitted in
the spec.

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

   I think we've agreed to stop using that word.

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

   I've agreed to stop trying to draw a distinction between "retrofit"
and "tunnel".

> It's the other way around more likely. The edges of the internet are 
> more likely to go NEW first...

   We've agreed that we should spec a transition which can work
either way (backbone going 4-byte first or edges going 4-byte first).

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

   We've made some progress here. We're still hung up over calling it
an "error", but we've agreed it could happen in the wild, and that
a BGP speaker with AS > 65535 _should_ discard 4-byte NLRIs containing
it, since they could represent routing loops.

--
John Leslie <john@jlc.net>

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