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

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Thu, 13 Sep 2007 18:43:02 -0700

Hi,

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. However, the RFC doesn't specific whether a
NEW BGP Speaker can or can not use AS-TRANS as its AS number.

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.

Please let me know if there are any restrictions for NEW BGP Speaker's
AS number.

Thanks,

Kalpesh

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

---

From: Geoff Huston <[email-masked]>
Date: Sun, 16 Sep 2007 08:20:30 +1000

AS23456 is not assigned to any end user by any RIR nor is it a 
designated private use AS - so how exactly do you see it being "used" by 
NEW BGP speakers other than in the context of being a bogon?

So a NEW BGP speaker should not be seeing AS23456 as a peer.

On a related note, an OLD BGP speaker should not perform SSLD on those 
updates where the peer is AS23456 and there is  AS23456 in the AS path.

Kalpesh Zinjuwadia wrote:
> ------------------------------------------------------------------------
>

---

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Mon, 17 Sep 2007 10:55:44 -0700

Thanks Geoff for clarification. I had this concern from an
implementation point of view and wanted to make sure that all conditions
(howsoever bogus it may be) are taken care of.

Thanks,
Kalpesh

---

From: Paul Jakma <[email-masked]>
Date: Tue, 25 Sep 2007 20:04:40 +0100 (IST)

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.

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

regards.
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
If you flaunt it, expect to have it trashed.

---

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Tue, 25 Sep 2007 12:35:48 -0700

See inline...

Thanks,
Kalpesh

-----Original Message-----
From: Paul Jakma [mailto:[email-masked]] 
Sent: Tuesday, September 25, 2007 12:05 PM
To: Kalpesh Zinjuwadia
Cc: [email-masked]
Subject: Re: [Idr] RFC 4893 - Question regarding AS-TRANS

Kalpesh: True. OLD speaker DON'T follow the RFC. I meant having the
check (for OLD peer's AS) on the NEW speaker.

Kalpesh: Open message will contain AS-TRANS if NEW speaker's AS is
non-mappable 4-byte AS. What I wanted to know is can a NEW speaker be
configured to belong to AS-TRANS (from implementation point of view).
Your and Geoff's replies answered my question.

       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.

or

regards.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 25 Sep 2007 21:00:25 +0100 (IST)

> check (for OLD peer's AS) on the NEW speaker.

I wouldn't recommend that.

A 'receiving' NEW speaker can't tell if the other side really is OLD, 
or a NEW speaker pretending to be OLD. E.g. imagine if a NEW speaker 
had an option to administratively configure 4/2 bytes on a per 
session basis (e.g. for testing, or as a short-term workaround for 
some implementation issue).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
crop circles in the corn shell

---

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Tue, 25 Sep 2007 14:30:26 -0700

How would a NEW speaker know whether the peer is genuinely OLD speaker
or it's NEW speaker pretending to be OLD (peer didn't send AS4 support
capability)?

If the session is established with an OLD speaker w/ AS 23456, there are
chances that peer will wrongly detect AS-PATH loops in the updates it
receives from the NEW peer. If all updates are from a NEW speaker w/
4-octet non-mappable AS, none of them would be installed in OLD
speaker's RIB.

OLD speaker's operator has to be aware of such cases. To avoid
consumption of n/w bandwidth and other resources in cases like above, I
was wondering of having the check on NEW speaker side.

Let me know your comments.

Thanks,
Kalpesh

-----Original Message-----
From: Paul Jakma [mailto:[email-masked]] 
Sent: Tuesday, September 25, 2007 1:00 PM
To: Kalpesh Zinjuwadia
Cc: [email-masked]
Subject: RE: [Idr] RFC 4893 - Question regarding AS-TRANS

regards,

---

From: Geoff Huston <[email-masked]>
Date: Wed, 26 Sep 2007 08:25:44 +1000

Paul Jakma wrote:
>> 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).
> 
>> be scenarios where re-constructing the as-path information from 
> The whole section on reconstruction is pretty ambigious, but hey. Also, 
> in hindsight, this (from 4.2.3):
> 

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:

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

---

From: Paul Jakma <[email-masked]>
Date: Wed, 26 Sep 2007 11:26:45 +0100 (IST)

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

> 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,
Internet outage

---

From: Paul Jakma <[email-masked]>
Date: Wed, 26 Sep 2007 20:11:20 +0100 (IST)

Hi Kalpesh,

On Tue, 25 Sep 2007, Kalpesh Zinjuwadia wrote:

> How would a NEW speaker know whether the peer is genuinely OLD 
> speaker or it's NEW speaker pretending to be OLD (peer didn't send 
> AS4 support capability)?

> If the session is established with an OLD speaker w/ AS 23456, 
> there are chances that peer will wrongly detect AS-PATH loops in 
> the updates it receives from the NEW peer.

How so?

Over a 2-byte session, the NEW speaker must receive an AS4_PATH if 
there were any >65535 ASN speakers in the path. The speaker would 
then reconcile AS4_PATH and the (2-byte) AS_PATH, to form the full 
(4-byte) AS_PATH.

> If all updates are from a NEW speaker w/ 4-octet non-mappable AS, 
> none of them would be installed in OLD speaker's RIB.

No. See above. Should get a full (4-byte) AS_PATH by reconciling 
AS4_PATH and (2-byte) AS_PATH.

> above, I was wondering of having the check on NEW speaker side.

Bad idea, IMHO.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
TV is chewing gum for the eyes.
 		-- Frank Lloyd Wright

---

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Wed, 26 Sep 2007 13:40:10 -0700

I meant that the routing loop would be wrongly detected on the OLD peer
side as it's AS is 23456 and the AS-PATH from NEW peer may contain 23456
as place-holders. The actual AS would be some 4-octet non-mappable ASN
in the AS4-PATH attr, which is unknown opt-trans for the OLD speaker.

Also, consider the case with a NEW speaker belonging to 4-octet
non-mappable AS. Per RFC, it would send 23456 in the "My AS" field of
Open Msg and add the 4-BYTE-AS capability with correct AS. If the peer
is OLD belonging to AS 23456 and if it ignores the capability as
unrecognized, it will wrongly treat the NEW speaker as IBGP (instead of
EBGP) peer, which is wrong...

Please let me know if I'm missing something.

Thanks,
Kalpesh

-----Original Message-----
From: Paul Jakma [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2007 12:11 PM
To: Kalpesh Zinjuwadia
Cc: [email-masked]
Subject: RE: [Idr] RFC 4893 - Question regarding AS-TRANS

Hi Kalpesh,

How so?

Bad idea, IMHO.

regards,

---

From: Enke Chen <[email-masked]>
Date: Wed, 26 Sep 2007 14:13:21 -0700

AS 23456 is reserved.  It means that the AS number is not, and will not 
be assigned to any organization.  It also means that the AS number has a 
special use, and must not be used in any way other than as designated.

If some one insists on using it, bad things (e.g., partial connectivity) 
will happen.  It is really no different from the unauthorized use of any 
other AS numbers.

-- Enke

---

From: Geoff Huston <[email-masked]>
Date: Thu, 27 Sep 2007 09:07:53 +1000

> has been munged in some way by (likely) an OLD speaker.

I requested an example of such a situation, and while I appreciate that 
you fail to see how it is possible to perform loop detection in such 
cases, that is not the same as providing a specific example where that 
really is the case that a loop is not detected.

On the other hand, <http://www.potaroo.net/ispcol/2007-01/asn32.html> 
has text that describes how loops are detected when the NEW_AS_PATH 
information is discarded at anypoint in the OLD BGP path. Perhaps you 
should have a look through that before proposing solutions for what 
appears to be non-problems

---

From: Paul Jakma <[email-masked]>
Date: Thu, 27 Sep 2007 09:38:24 +0100 (IST)

On Thu, 27 Sep 2007, Geoff Huston wrote:

> I requested an example of such a situation, and while I appreciate 
> that you fail to see how it is possible to perform loop detection 
> in such cases, that is not the same as providing a specific example 
> where that really is the case that a loop is not detected.

I gave two examples.

> Perhaps you should have a look through that before proposing 
> solutions for what appears to be non-problems

The text is describing error-handling. It's hard to account in 
advance for how errors will arise (if it weren't, we'd try to 
engineer things to avoid the error).

The text however is broken (we discussed these cases here on IDR 
prior to the final spin of the draft too). If this error case is 
inconsequential, then that broken text should be removed.

Anyway...

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Data, n.:
  	An accrual of straws on the backs of theories.