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

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	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Internet outage

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