headers
rfc-editor | 8 Sep 02:40
Favicon

RFC 5004 on Avoid BGP Best Path Transitions from One External to Another


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5004

        Title:      Avoid BGP Best Path Transitions 
                    from One External to Another 
        Author:     E. Chen, S. Sangli
        Status:     Standards Track
        Date:       September 2007
        Mailbox:    enkechen <at> cisco.com, 
                    rsrihari <at> cisco.com
        Pages:      6
        Characters: 11437
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-idr-avoid-transition-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5004.txt

In this document, we propose an extension to the BGP route selection rules
that would avoid unnecessary best path transitions
between external paths under certain conditions.  The proposed extension
would help the overall network stability, and more importantly, would
eliminate certain BGP route oscillations in which more than one external
path from one BGP speaker contributes to the churn.  [STANDARDS TRACK]

This document is a product of the Inter-Domain Routing
Working Group of the IETF.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kalpesh Zinjuwadia | 14 Sep 03:43
Favicon

RFC 4893 - Question regarding AS-TRANS

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
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 2 comments |
headers
Geoff Huston | 16 Sep 00:20
Favicon
Gravatar

Re: RFC 4893 - Question regarding AS-TRANS

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:
> 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
> Idr <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Kalpesh Zinjuwadia | 17 Sep 19:55
Favicon

RE: RFC 4893 - Question regarding AS-TRANS

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

-----Original Message-----
From: Geoff Huston [mailto:gih <at> apnic.net] 
Sent: Saturday, September 15, 2007 3:21 PM
To: Kalpesh Zinjuwadia
Cc: idr <at> ietf.org
Subject: Re: [Idr] RFC 4893 - Question regarding AS-TRANS

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:
> 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
> Idr <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Paul Jakma | 25 Sep 21:04
Picon

Re: RFC 4893 - Question regarding AS-TRANS

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	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
If you flaunt it, expect to have it trashed.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 5 comments |
headers
Kalpesh Zinjuwadia | 25 Sep 21:35
Favicon

RE: RFC 4893 - Question regarding AS-TRANS

See inline...

Thanks,
Kalpesh

-----Original Message-----
From: Paul Jakma [mailto:paul <at> clubi.ie] 
Sent: Tuesday, September 25, 2007 12:05 PM
To: Kalpesh Zinjuwadia
Cc: idr <at> ietf.org
Subject: Re: [Idr] RFC 4893 - Question regarding AS-TRANS

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

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

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

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.

> 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	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
If you flaunt it, expect to have it trashed.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Paul Jakma | 25 Sep 22:00
Picon

RE: RFC 4893 - Question regarding AS-TRANS

On Tue, 25 Sep 2007, Kalpesh Zinjuwadia wrote:

> Kalpesh: True. OLD speaker DON'T follow the RFC. I meant having the
> 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	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
crop circles in the corn shell

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Kalpesh Zinjuwadia | 25 Sep 23:30
Favicon

RE: RFC 4893 - Question regarding AS-TRANS

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:paul <at> clubi.ie] 
Sent: Tuesday, September 25, 2007 1:00 PM
To: Kalpesh Zinjuwadia
Cc: idr <at> ietf.org
Subject: RE: [Idr] RFC 4893 - Question regarding AS-TRANS

On Tue, 25 Sep 2007, Kalpesh Zinjuwadia wrote:

> Kalpesh: True. OLD speaker DON'T follow the RFC. I meant having the
> 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	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
crop circles in the corn shell

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Geoff Huston | 26 Sep 00:25
Favicon
Gravatar

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
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 3 comments |
headers
Paul Jakma | 26 Sep 12:26
Picon

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

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 2 comments |

Gmane