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

[John Leslie <[e-mail]>]

Paul Jakma <[e-mail]> wrote:
> On Mon, 10 Oct 2005, John Leslie wrote:
> 
> >]    *  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.
> >
> >  It seems to me that NEW_AS_PATH information inconsistent with
> >  AS_PATH information MUST be discarded. Can't we say so?
> 
> I'd say the whole UPDATE would have to be discarded, you have no way 
> of knowing exactly which of the two paths is "wrong", nor any way to 
> properly reconstruct the path.

   Recall that the _result_ of all our routing-protocol machinations is
that a packet will be passed to the "most appropriate" next-hop.

   Thus, IMHO, what the peer-you-will-choose doesn't know, can't help
you.

   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. Thus, we know which one
is "better".

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

>>] AS_PATH attribute). This AS path information should be prepended to
>>] the NEW_AS_PATH attribute to construct the exact AS path information.
>>
>> This last sentence is inconsistent with discarding NEW_AS_PATH
>> information which is inconsistent with AS_PATH information.
> 
> Indeed, but the draft does not specify anywhere what action (if any) 
> should be taken if the paths are found to be inconsistent. But that 
> might be cause it doesn't describe in any meaningful way how to 
> reconcile the different paths.

   I really don't see any way to "reconcile" the paths. I've stated
my preference; the draft seems to choose the opposite direction.
Possibly we can nag Bill or Alex into suggesting a resolution.

>>  I find this worrisome. Any OLD BGP speakers will have been quite 
>> unaware of the meaning of NEW-AGGREGATOR attributes they pass on. I 
>> don't think we can ensure they _never_ introduce or modify an 
>> AGGREGATOR attribute. I would be more comfortable if we examined 
>> any NEW-AGGREGATOR attribute to clarify ambiguity in 2-octet 
>> numbers in the AGGREGATOR attribute.
> 
> 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.

> >  There is a philosophical question here: whether we're 
> > retrofitting 4-octet AS numbers into an existing system, or whether 
> > we're piecing together a new system of 4-octet AS numbers with some 
> > fudging of how we tunnel through existing systems. Personally, I 
> > prefer the first.
> 
> I think it's a bit of both.

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

>> Instead, we'd do well to match the trailing n ASNs, substituting 
>> 4-octet ASNs for AS_TRANS while the match remains good -- and 
>> dropping back to the original AS_PATH if the match fails.
> 
> If the match fails, you have no clue who ferked up. NEW_AS_PATH 
> /should/ be the canonical path information though for the further 
> portion of the composite path. But if the further portion of the 
> 2-byte path does not coincide with the same further portion of the 
> NEW_AS_PATH then either:
> 
> - an OLD speaker decided to modify bits of the path prior to it
> 	- eg to aggregate it, in which case reconstructing the full
> 	  composite PATH involves more than just appending/prepending
> - the NEW speaker who formed the NEW_AS_PATH screwed up
> 
> - ???

   Mostly (IMHO), it's the second case.

   Let us not forget that the "B" of "BGP" is for "border". IOW,
the border of what we have good reason to trust. We're getting stuff
from peers we have limited reason to trust. They're passing on stuff
from peers _they_ have limited reason to trust. So most of the stuff
we deal with we have _no_ good reason to trust: it's merely "good
enough for best-effort".

   The days are _long_ gone when we could trust BB&N to keep all the
routing information consistent. If there ever was a time we could
trust Cisco to keep stuff consistent throughout the network of their
routers, that too is long gone.

>> (There is a weird case where the matching 4-octet AS _is_ 
>> AS_TRANS, which IMHO is _not_ an error.)
> 
> It is an error, AS_TRANS is reserved and its only described use is to 
> denote 4-byte ASNs in 2-bytes. Hence there is no reason (within this 
> draft at least) to see it in 4-byte space.

   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.

>> I'd frankly prefer a full algorithm: otherwise we can't put very
>> much confidence in the result.
>>
>> But I'll admit that differing algorithms _might_ not be especially
>> harmful, so long as they preserve the AS_PATH _length_...
> 
> The draft at least should state what it *intends the result* from 
> merging the OLD and NEW paths to be, and perhaps offer one example 
> algorithm.

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

--
John Leslie <[e-mail]>

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