Re: [Idr] RFC 4893 - Question regarding AS-TRANS

Paul Jakma wrote:
> On Thu, 13 Sep 2007, Kalpesh Zinjuwadia wrote:
> 
>> I had a question regarding AS-TRANS as defined in RFC 4893. It clearly 
>> states that AS-TRANS is reserved by the IANA and an OLD BGP Speaker 
>> MUST NOT use it as its AS number.
> 
> Not really a requirement that OLD speakers can enforce - by definition 
> they don't implement the draft (operators of OLD speakers can try avoid 
> using AS_TRANS..).
> 
>> However, the RFC doesn't specific whether a NEW BGP Speaker can or can 
>> not use AS-TRANS as its AS number.
> 
> 4.2.1 seems to clearly state that NEW speakers may use AS_TRANS as their 
> local ASN to peer with OLD ones.

This is performed by the NEW speaker when peering with an OLD speaker as 
a substitute value for the 32 bit value.

> 
> Other than that, AS_TRANS isn't specified for use (as AS for a speaker 
> anyway).
> 
>> I ask this question because if a NEW BGP Speaker CAN use it, there can 
>> be scenarios where re-constructing the as-path information from 
>> AS-PATH and AS4-PATH attributes received in update from OLD BGP 
>> Speaker can be ambiguous.
> 
> The whole section on reconstruction is pretty ambigious, but hey. Also, 
> in hindsight, this (from 4.2.3):
> 
>       If the number of AS numbers in the AS_PATH attribute is less than the
>       number of AS numbers in the AS4_PATH attribute, then the AS4_PATH
>       attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken
>       as the AS path information.
> 
> is just bogus. By throwing away AS4_PATH, you're opening up to loops. 

My analysis of this situation is that this is not the case and that such 
an action does _not_ lead to persistent loops.

I would be interested to understand your reasoning and the specific 
case(s) you have in mind here where you believe that discarding the 
AS4_PATH leads to the formation of a loop (as distinct from the delayed 
detection of a loop).

In
> the above case, either:
> 
> - The loop-detection property should be preserved as much as
>      possible, i.e. construct a path containing /all/ the ASes in
>      both paths at least once.
> 
> or
> 
> - Discard the UPDATE as invalid
> 

I believe that this advice is inappropriate and that it is valid to 
retain the 16 bit path  and discard the AS4_PATH, with the side effect 
that loop detection takes longer, but the essential attribute of loop 
prevention is retained in this case.

Geoff

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