Re: 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
Idrietf.org
https://ww
w1.ietf.org/mailman/listinfo/idr

On Wed, 26 Sep 2007, Geoff Huston wrote:

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

Hmm, the draft doesn't say that. It's says NEW speakers can
use 
AS_TRANS if they do not have a unique 2-bit ASN:

    However, this document does not assume that an
Autonomous System with
    NEW speakers has to have a globally unique 2-octet AS
number --
    AS_TRANS could be used instead (even if a multiple
Autonomous System
    would use it).

Seems obvious that "<without> a globally unique
2-octet AS number" 
means to imply the AS does have a unique 4-byte one, doesn't
quite 
say it. Something for a future respin to clarify .

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

If one throws away AS4_PATH, I fail to see how it is
possible to then 
detect loops through ASes with ASNs > 65535, given you
/know/ AS_PATH 
has been munged in some way by (likely) an OLD speaker.

It can not be assumed that AS_TRANS will be in the AS_PATH
because 
this case will arise most likely where an OLD speaker has
munged 
AS_PATH in some unknown way (unaware of AS4_PATH) or else,
worse (but 
hopefully unlikely), buggy speakers (heightened possibility
of this 
when deploying new features, like AS4).

So the options seem to be:

- 'Fix' by ensuring AS_PATH contains AS_TRANS, discarding
AS4_PATH.

   - should prevent loops in 2-byte space
   - unclear what a NEW speaker downstream might do if it
has to
     reconcile such a fixed AS_PATH (containing AS_TRANS)
with
     a fresh AS4_PATH.
     - blackholes the route to any onward NEW ASes, at
best.
     - but could trigger strange AS_PATH reconciliation
(AS_TRANS in
       2-byte AS_PATH might be used as a marker to find the
splicing
       point..).

- Generate a new AS_PATH that preserves all distinct ASNs in
the
   AS_PATH and AS4_PATH (e.g. append latter), and so
preserves
   loop-detection properties as much as possible

   - traffic engineering based on path-lengths/relationships
may not
     work
   - still some risk of loops, simply cause we can't know
exactly why
     AS_PATH got munged
   - But presuming AS_PATH is loop-free (from a 2-byte POV),
and
     AS4_PATH wasn't modified, then this option should not
introduce
     loops or blackholes.

- Discard the UPDATE

   - bit severe, but less risky than first option to my mind
at
     moment.

regards,
-- 
Paul Jakma	paulclubi.ie	pauljakma.org	Key ID: 64A2FF6A
Fortune:
Internet outage

_______________________________________________
Idr mailing list
Idrietf.org
https://ww
w1.ietf.org/mailman/listinfo/idr