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

[John Leslie <[e-mail]>]

Paul Jakma <[e-mail]> wrote:
> 
> 1. Surely the questions raised in the implementation report should
>    first be at least examined, if not addressed?

   To be specific, Juniper reports:
] 
] Are there parts of the specification that are unclear where the
] implementor had to exercise some judgement that may impact
] interoperability?
]    *  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?

]    *  There some places where AS numbers are used where it wasn't
]       clear how to deal with 4-octet as-numbers (e.g. extended
]       communities).

   This isn't clear to me, either.

]    *  It isn't spelled out that this capability cannot be dynamically
]       negotiated.

   Actually, I _can_ think how to dynamically negotiate it, but it
seems like a bad idea.

> (concerns 5.2.3 at least, see 3.).
] 
] Note that a route may have traversed a series of autonomous systems
] with 2-octet AS numbers and OLD BGP speakers only. In that case, if
] the route carries a NEW_AS_PATH attribute, this attribute may not
] have been updated since the route left the last NEW BGP speaker. The
] trailing AS path information (representing autonomous systems with
] 2-octet AS numbers and OLD BGP speakers only) is contained only in
] the current AS_PATH attribute (encoded in the leading part of the
] 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.

] Similarly, a NEW BGP speaker should be prepared to receive the
] NEW_AGGREGATOR attribute from an OLD BGP speaker. In that case, the
] AGGREGATOR attribute is ignored and the NEW_AGGREGATOR contains the
] exact information about the aggregating node.

   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.

   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.

> 2. Section 5.3 should be deleted, I'm not sure how this draft could
>    ever mandate behaviour for OLD speakers, when OLD specifically is
>    defined to be those peers which do not implemented the extensions
>    defined in the draft. ;)
] 
] In all other cases the speaker MUST encode Autonomous System numbers
] as 2-octet entities in both the AS_PATH and the AGGREGATOR attribute
] in the updates it sends to the peer, and MUST assume that these
] attributes in the updates received from the peer encoded Autonomous
] System numbers as 2-octet entities.

   Our problem is discerning a meaning for "all other cases". I don't
think there _is_ a clear meaning here. The section title suggests
we're specifying what an OLD BGP speaker MUST do; and that's simply
wrong.

   Deleting the secton seems easiest...

> 3. NEW_AS_PATH parsing/actions are barely specified.
> 
> Eg:
> 
>    NEW       NEW       NEW      OLD       OLD     NEW
>    AS256---AS200000---AS512---AS1024---AS2048---AS4096
> 
> 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.

> AS4096 would receive:
> 
> AS_PATH:	seq(2048,1024,512,AS_TRANS,256)
> NEW_AS_PATH:	seq(200000,256)
> 
> 5.2.3 states that:
> 
> "<leading part of AS_PATH information> should be prepended to the 
> NEW_AS_PATH attribute to construct the exact AS path information."
> 
> Where "leading part" are those ASN that are only 2-byte and OLD. But 
> we're not told how one should deduce where this leading part 
> finishes. The simplistic approach of "closest AS_TRANS marks end of 
> leading part",

   This is a very bad algorithm.

   We cannot, IMHO, ensure that AS_TRANS will not somehow get inserted
into a path without there being a corresponding entry in NEW_AS_PATH.
Thus, assuming that the closest AS_TRANS is the demarcation cannot
give dependable results.

   (However, Paul is exploring a different problem:)

> which is suggested by definition of "leading part" would give us:
> 
> 	seq(2048,1024,512,200000,256)
> 
> Which is the correct result, however the method is wrong. Imagine if 
> the 200000 and 256 are the other way around:
> 
> AS_PATH:	seq(2048,1024,512,256,AS_TRANS)
> NEW_AS_PATH:	seq(256,200000)
> 
> Using previous method would give:
> 
> 	seq(2048,1024,512,256,256,200000)
> 
> Which result is wrong :). Obviously, one should use the n #-of-ASNs 
> in the *NEW_AS_PATH* as the *trailing* part of the real AS_PATH 
> information and override the last n ASNs in the AS_PATH. So why 
> doesn't the draft state this? ;)

   Paul's algorithm looks safer...

   But IMHO we'd be poorly advised to blindly adopt it either.
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.

   (There is a weird case where the matching 4-octet AS _is_ AS_TRANS,
which IMHO is _not_ an error.)

> I.e. The full process should preferably be *documented* in the draft, 
> but at a minimum this vague (if not slightly misleading) 'prepend 
> leading part of AS_PATH' language should be removed.

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

> Also, if a process to reconcile AS_PATH and NEW_AS_PATH is to be 
> described (I think it should ;) ), obvious questions arise, as 
> one responder to the implementation report hints at:
> 
>   a) Should/Must the "overriden" ASNs in the AS_PATH be reconciled
>      against the NEW_AS_PATH ASNs which are replacing them?

   (I, of course, don't believe the should be "overridden" -- merely
disambiguated.)

>   b) If so, what if they can /not/ be reconciled?

   We're poorly advised to leave _that_ question "as an exercise to
the student".

   I'm convinced that regardless of what we spec, NEW BGP speakers
_will_ receive AS_TRANS entries with no disambiguating NEW_AS_PATH
entry. This doesn't seem fatal: the worst effect which jumps out is
failure to detect loops (which seems fairly innocuous: detecting
loops where none exist would be a much more serious failing).

--
John Leslie <[e-mail]>

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