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

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.

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

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

>> 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)
>
>   Actually, I don't think it's clear whether this NEW_AS_PATH should
> or should not contain 512.

Yes, that's what I was hinting at with "AS_PATH as received 
previously presumably" ;)

>   Paul's algorithm looks safer...
>
>   But IMHO we'd be poorly advised to blindly adopt it either.

Oh, ACK.

> 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 proir 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

- ???

Actually, is the "OLD speaker aggregated" case even discussed in the 
draft?

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

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

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Ignorance must certainly be bliss or there wouldn't be so many people
so resolutely pursuing it.

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