Subject: Re: [Idr] Comments on RFC4893

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 1 Feb 2008 10:34:55 -0800

Hi,

There is just one small part I wanted to clarify.

> Clarification 3
> ============
> Section 3 of RFC4893 states:
> "NEW BGP speakers carry AS path information expressed in terms of
> 4-octet Autonomous Systems numbers by using the existing AS_PATH
> attribute, except that each AS number in this attribute is encoded not
> as a 2-octet, but as a 4-octet entity."
>  o-------------------o----------------------o-------------------
>   NEW1                NEW2               OLD2                    OLD3
> =====> Route Adv
>
> In the above sequence of configuration, how does the OLD2 process the
> 4byte ASN value in the AS_PATH  put by NEW1 ? The OLD BGP implementation
> is expected to use 2byte ASN value.  Please clarify.
> Should not it be easy and backward compatible if NEW BGP speakers always
> use AS4_PATH for 4byte ASN and use AS_PATH only when the ASNs
> are mappable to 2bytes?
>
> Kalpesh> NEW1 & NEW2 will exchange update with 4-byte AS-PATH & AGGR
> attributes. However, when NEW2 advertises update to OLD2, it will split
> 4-byte AS-PATH attribute into 2-byte AS-PATH and 4-byte AS4-PATH using
> the steps mentioned in RFC. Same goes for AGGR attribute. OLD2 & OLD3
> will treat AS4-PATH & AS4-AGGR attributes as unknown opt-trans and pass
> it further.

When the New router sends the update with the old router, it converts the 4 byte
AS-Path to 2 byte AS-Path, with procedures mentioned in the RFC. As the OLD
routers do not understand the AS4_PATH they will just opaquely forward the
AS4_PATH attribute - which is an optional Transitive attribute.
We will then get the same value in the attribute when an OLD router
communicates
with a new. The idea is to transport 4-byte AS numbers Opaquely and
translating at
the edge the AS_PATH attribute to carry only 2 byte AS-Numbers (by using
AS-TRANS value).

Thanks,
Vishwas

On Jan 31, 2008 8:15 PM, Kalpesh Zinjuwadia
<[email-masked]> wrote:
> Some comments inline.
>
> Thanks,
> Kalpesh
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Samita Chakrabarti
> Sent: Thursday, January 31, 2008 6:46 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [Idr] Comments on RFC4893
>
> Hello Quaizar and Enke:
>
> While reviewing RFC4893 (4-byte AS Number support for BGP), I have
> encountered several questions related to interoperability and
> implementation.
>
> I am listing them below; my apology if they are already discussed in
> this
> list before. (I am new in this mailing list)
>
> It seems to me that the RFC has ambiguity in several places that needs
> to be
> corrected from implementation perspective. Is there a plan for a
> revision?
>
> Regards,
> -Samita
> ------------------------------------------------------------------------
> ----
> ------------------------------------------------------------------------
> ----
> RFC4893 is unclear about the processing of "My ASN" field in the OPEN
> message. Section 3
>  mentions about the capability message for 4byte ASN support:
>
> "The Capability that is used by a BGP speaker to convey to its BGP peer
> the
> 4-octet Autonomous System number
>  capability, also carries the 4-octet Autonomous System number of the
> speaker in the Capability Value field of the
>  Capability Optional Parameter. The Capability Length field of the
> Capability is set to 4. "
>
> and
> "We denote this special AS number as AS_TRANS for ease of description in
> the
> rest of this
>  specification. This AS number is also placed in the "My Autonomous
> System"
> field of the
> OPEN message originated by a NEW BGP speaker, if the speaker does not
> have a
>  (globally unique) 2-octet AS number."
>
>
> Clarification 1:
> ============
> In section 4 it describes the interaction between NEW BGP speakers; it
> discusses the UPDATE
> message processing with
> NEW and OLD BGP speakers. But  it does not discuss the OPEN message
> send/recv in details;
> the following cases need clarification:
> 1) NEW BGP speakers interactions: If the BGP speaker has a 2byte unique
> ASN
> it uses the
>    2 byte ASN in the "My ASN" field of OPEN message. If the BGP speaker
> has
> a 4 byte
>    non-mappable AS number, then it  uses AS_TRANS in "My ASN" field of
> OPEN
> message.
> 2) Receiving OPEN message: If a NEW BGP speaker receives a OPEN message
> with
> extended ASN
>    capability, then it ignores the "My ASN" field of OPEN message and
> uses
> the 4byte ASN
>    value in the capability message. [ this will clarify the
>    ambiguity  and increases interoperability ]
>
> Kalpesh> NEW BGP speaker (R1) will always put the 4-BYTE-AS capability
> in the Open message, unless it's acting as OLD. "My AS" will contain the
> actual AS if it's mappable to 2-byte field; else it will contain
> AS-TRANS. OLD speaker (R2) will use AS-TRANS as R1's AS. NEW speaker
> (R3) will use the ASN in the capability as R1's AS. R3 may also put
> sanity check such as "My AS" can be AS-TRANS iff R1's actual ASN is
> 4-byte non-mappable.
>
>
> Clarification 2:
> =============
> Scenario for AS_PATH.
>
> o-------------------o-------------------o----------------------o--------
> -o
>  OLD                     NEW                   NEW           OLD
> NEW
>  (50)                    (5000)             (65666)      (101)
> (65777)
>
> The RFC says that :
> "4.2.1. BGP Peering Note that peering between a NEW BGP speaker and an
> OLD
> one is possible
> only if the NEW BGP speaker has a 2-octet AS number. 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)."
> -------
> From the above text it is not clear whether a NEW BGP speaker with 4byte
> non-mappable ASN
>  can talk to the OLD BGP speaker or not.Practically it is not possible
> to
> communicate with
>  OLD and NEW BGP peer with non-mappable 4byte ASN (see the above
> scenario
> where both peers of
> a OLD BGP are NEW with 4byte ASN). I assume that the RFC recommends :
>      1)  If the NEW BGP speaker has a unique 2 byte ASN or a
> 2-byte-mappable
> 4byte ASN, it
>            SHOULD use the 2 byte ASN in the "My ASN field" for OPEN
> message.
>      2) The NEW BGP with non-mappable 4byte ASN SHOULD not peer with OLD
> BGP
> speaker;
>            this can easily produce routing loop or loss of ASN value in
> the
> PATH.
>
> Kalpesh> I don't know if I understand your question completely. However,
> I don't think RFC puts any restriction on NEW BGP speaker with
> non-mappable 4-byte ASN to communicate with OLD & NEW BGP speakers at
> the same time. In your case, NEW speaker w/ ASN 65666 will communicate
> differently with NEW speaker w/ ASN 5000 and OLD speaker w/ ASN 101.
> Each speaker pair should be is treated independently and not confused
> with others.
>
>
> Clarification 3
> ============
> Section 3 of RFC4893 states:
> "NEW BGP speakers carry AS path information expressed in terms of
> 4-octet
> Autonomous Systems
>  numbers by using the existing AS_PATH attribute, except that each AS
> number
> in this
>  attribute is encoded not as a 2-octet, but as a 4-octet entity."
>
>  o-------------------o----------------------o-------------------
>   NEW1                NEW2               OLD2                    OLD3
> =====> Route Adv
>
> In the above sequence of configuration, how does the OLD2 process the
> 4byte
> ASN value in
> the AS_PATH  put by NEW1 ? The OLD BGP implementation is expected to use
> 2byte ASN value.
>  Please clarify.
> Should not it be easy and backward compatible if NEW BGP speakers always
> use
> AS4_PATH for
> 4byte ASN and use AS_PATH only when the ASNs are mappable to 2bytes?
>
> Kalpesh> NEW1 & NEW2 will exchange update with 4-byte AS-PATH & AGGR
> attributes. However, when NEW2 advertises update to OLD2, it will split
> 4-byte AS-PATH attribute into 2-byte AS-PATH and 4-byte AS4-PATH using
> the steps mentioned in RFC. Same goes for AGGR attribute. OLD2 & OLD3
> will treat AS4-PATH & AS4-AGGR attributes as unknown opt-trans and pass
> it further.
>
>
> Clarification 4
> ================
>
> When the NEW BGP speaker has a non-mappable 4byte unique AS number and
> it is
> peering with an OLD BGP
> speaker, only then should it use AS_TRANS in AS_PATH and a corresponding
> AS4_PATH 4byte
>  AS number?
> This should simplify reconstructing the AS number from both AS_PATH and
> AS4_PATH and also
> is in sync with AS4_AGGREGATOR processing as described in the RFC.
>
> Kalpesh> NEW speaker will generate AS4-PATH only if the AS-PATH to be
> sent to OLD peer has at least 1 non-mappable 4-byte ASN. Hence, a NEW
> speaker with 2-byte mappable AS may generate AS4-PATH if reqd.
>
> section 4.2.2:
> "When communicating with an OLD BGP speaker, a NEW speaker MUST send
>    the AS path information in the AS_PATH attribute encoded with 2-octet
>    AS numbers.  The NEW speaker MUST also send the AS path information
>    in the AS4_PATH attribute (encoded with 4-octet AS numbers), except
>    for the case where the entire AS path information is composed of 2-
>    octet AS numbers only.  In this case, the NEW speaker SHOULD NOT send
>    the AS4_PATH attribute."
>
> The above rule is confusing from the implementation perspective. How
> about
> making it simple by doing the same thing as AS_AGGREGATOR (as follows) ?
>
>   "Similarly, if the NEW speaker has to send the AGGREGATOR attribute,
>    and if the aggregating Autonomous System's AS number is truly 4-
>    octets, then the speaker constructs the AS4_AGGREGATOR attributes by
>    taking the attribute length and attribute value from the AGGREGATOR
>    attribute and placing them into the attribute length and attribute
>    value of the AS4_AGGREGATOR attribute, and sets the AS number field
>    in the existing AGGREGATOR attribute to the reserved AS number,
>    AS_TRANS.  Note that if the AS number is 2-octets only, then the
>    AS4_AGGREGATOR attribute SHOULD NOT be sent."
>
> I assume that "truly 4-octet" means it is higher than 65535.
>
> Kalpesh> I think conditions mentioned for generating AS4-PATH & AS4-AGGR
> are inherently same. For AS-PATH all ASN in it are considered for AGGR
> the aggregating ASN is considered.
>
> Yes "truly 4-octet" ASN means ASN > 65535.
>
> Clarification 5
> ===================
>
> Should the NEW BGP speaker send a NOTIFICATION with error code =2 and
> subcode=7
> (unsupported capability) when it receives a OPEN message with AS_TRANS
> but
> without
> any corresponding capability message ?
>
> Kalpesh> RFC doesn't discuss how NEW speaker should behave when OLD
> speaker uses AS-TRANS in "My AS" field. Behavior is implementation
> dependent.
>
> Similarly, should a NEW BGP speaker with AS number higher than 65535,
> send a
>
> NOTIFICATION to a OLD BGP speaker with error code =2 and subcode=7,
> before
> closing the
> peering connection ?
>
> Kalpesh> What caused NEW BGP speaker to close the connection with OLD
> peer? If same as previous question, again it's implementation dependent.
>
>
> IMHO, the above NOTIFICATION is helpful for transition phase.
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/idr
>
_______________________________________________
Idr mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/idr

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 1 Feb 2008 11:51:54 -0800

Hi Kalpesh,

Thanks for the response. Please see in-line.

>AS-TRANS. OLD speaker (R2) will use AS-TRANS as R1's AS.
[SC>] 
[SC>]  Yes. We are saying the same thing. But the point is that the RFC is
not very clear about sending/receiving "My ASN" value in the OPEN message
and it should be clarified.

Kalpesh> NEW speaker
>sanity check such as "My AS" can be AS-TRANS iff R1's actual ASN is
[SC>] 
[SC>] What is your topology in this example? Is R3 peering with both R1 and
R2?  The question is should we allow R2 to peer with non-mappable ASN BGP
speaker in the following scenario?

    R1 (ASN=65566)-----R2(100)-------------R3(77777)-----R4(400)
     NEW              OLD BGP               NEW            OLD BGP
In this example, R4 finds loop in ASN path, because it can only understand
2byte AS_TRANS.  R4 sees <23456, 100, 23456> in ASN PATH.

The RFC in section 4.2.1 is very liberal about the specification; I think,
the RFC at least should recommend some valid scenarios and discourage things
that can cause interoperability or confusion in the BGP path.

>Each speaker pair should be is treated independently and not confused
[SC>] 
      Please see the previous example  of R1-R2-R3-R4 scenario.

>will treat AS4-PATH & AS4-AGGR attributes as unknown opt-trans and pass
[SC>] 
 
Yes. Again the RFC needs more clarification here, as well. 

>Clarification 4
[SC>] 
[SC>] 
      OK. It is now clarified. 
>the aggregating ASN is considered.
[SC>] 
[SC>]  Conditions for AS4_PATH and AS4_AGGR should be the same; again this
part is a bit unclear in the RFC.

>Yes "truly 4-octet" ASN means ASN > 65535.
[SC>] 
[SC>] This is also subject to interpretation in the RFC.

>Clarification 5
[SC>] 
[SC>] Please note the above situation can also happen from a faulty or
misbehaving NEW BGP speaker with non-mappable 4b ASN. Since AS_TRANS is a
reserved value and not assigned to anyone, if the OLD BGP speaker somehow
uses this value in the OPEN message, it must not be accepted either.
IMHO, this NOTIFICATION case is a valid one and should be documented.

-Samita

---

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Fri, 1 Feb 2008 12:28:33 -0800

Comments inline.

Thanks,
Kalpesh

-----Original Message-----
From: Samita Chakrabarti [mailto:[email-masked]] 
Sent: Friday, February 01, 2008 11:52 AM
To: Kalpesh Zinjuwadia; [email-masked]; [email-masked];
[email-masked]
Cc: 'Samita Chakrabarti'
Subject: RE: [Idr] Comments on RFC4893

Hi Kalpesh,

>Clarification 1:
[SC>] 
[SC>]  Yes. We are saying the same thing. But the point is that the RFC
is
not very clear about sending/receiving "My ASN" value in the OPEN
message
and it should be clarified.

<<Kalpesh>> I don't think there is any ambiguity in RFC for this. Can
you elaborate what's not clear to you?

Kalpesh> NEW speaker
>sanity check such as "My AS" can be AS-TRANS iff R1's actual ASN is
[SC>] 
[SC>] What is your topology in this example? Is R3 peering with both R1
and
R2?  The question is should we allow R2 to peer with non-mappable ASN
BGP
speaker in the following scenario?

    R1 (ASN=65566)-----R2(100)-------------R3(77777)-----R4(400)
     NEW              OLD BGP               NEW            OLD BGP
In this example, R4 finds loop in ASN path, because it can only
understand
2byte AS_TRANS.  R4 sees <23456, 100, 23456> in ASN PATH.

The RFC in section 4.2.1 is very liberal about the specification; I
think,
the RFC at least should recommend some valid scenarios and discourage
things
that can cause interoperability or confusion in the BGP path.

<<Kalpesh>> BGP speaker will only check for it's local AS in the
received AS-PATH and doesn't worry about multiple occurrence of other
ASes. Pl go thru RFC 4271, sec 9.1.2, 3rd para on pg 78.

[SC>] 

<<Kalpesh>> My previous comment should clarify your doubt.

[SC>] 

<<Kalpesh>> Pl elaborate if you see any ambiguity here.

[SC>] 
[SC>] 
      OK. It is now clarified. 
>the aggregating ASN is considered.
[SC>] 
[SC>]  Conditions for AS4_PATH and AS4_AGGR should be the same; again
this
part is a bit unclear in the RFC.

[SC>] 

<<Kalpesh>> I think "truly 4-octet ASN" always means same in RFC. Do you
notice different interpretation in RFC?

[SC>] 
[SC>] Please note the above situation can also happen from a faulty or
misbehaving NEW BGP speaker with non-mappable 4b ASN. Since AS_TRANS is
a
reserved value and not assigned to anyone, if the OLD BGP speaker
somehow
uses this value in the OPEN message, it must not be accepted either.
IMHO, this NOTIFICATION case is a valid one and should be documented.

<<Kalpesh>> Again, the behavior is implementation dependent.
-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 1 Feb 2008 12:52:10 -0800

Hi Kalpesh,

>you elaborate what's not clear to you?

[SC>] 
I'd like to see a section on OPEN message on sending and receiving clearly
for example. I am hearing questions and problems in understanding from the
engineers who are implementing this RFC. I have been involved with IETF
process for a long time and wish to see a revision of this RFC which does
not generate clarification questions for those who did not get involved
during the development of this RFC.

-Samita

---

From: Brian Dickson <[email-masked]>
Date: Tue, 05 Feb 2008 18:46:52 -0500

I've put together a new draft, with the (ambitious!) goal of addressing 
a few of the outstanding BGP issues:
- wedgies
- persistent oscillations
- path hunting.

I've included most of the supporting examples for the first two, which 
are clearly smaller in scope.

I'll be doing more work (between now and IETF-71) to produce example 
cases for the path hunting problem (w.r.t. the new draft).
My hope is this can reduce the level of induced churn caused by path 
hunting.

I'd respectfully request a slot in Philly to present this material.

Comments are obviously welcome, as well as any pointers to tools for 
evaluating path hunting behavior.

Obviously, adding new attributes isn't something to be done lightly, but 
if the results are compelling enough, it may be an appropriate path to take.

I'd appreciate it if we can first look to see if the results are 
compelling, before getting into whether they are compelling enough. :-)

Thanks,

Brian Dickson

> A new version of I-D, draft-dickson-idr-second-best-backup-00.txt has 
> been successfuly submitted by Brian Dickson and posted to the IETF 
> repository.
>
> Filename:        draft-dickson-idr-second-best-backup
> Revision:        00
> Title:           Enhanced BGP Capabilities for Exchanging Second-best 
> and Back-up Paths
> Creation_date:   2008-02-05
> WG ID:           Independent Submission
> Number_of_pages: 20
>
> Abstract:
> This Internet Draft describes an enhanced way to exchange prefix
> information, to permit multiple copies of a prefix with different
> paths to be announced and withdrawn.
>
> This negotiated capability provides faster local (inter-AS) and
> global (intra-AS) convergence, reduces path-hunting, improves route-
> reflector behaviour, including eliminating both persistent
> oscillations and BGP "wedgies".
>
> Additional prefix instances have new optional transtive BGP
> attributes, to control path selection.
>
> Withdrawl of prefixes will require path attributes.
>
> Benefits are seen both when deployed intra-AS, and on inter-AS
> peering.
> Author's Note
>
> This Internet Draft is intended to result in this draft or a related
> draft(s) being placed on the Standards Track for idr.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 5 Feb 2008 19:22:52 -0500

Hi Brian,

The draft-dickson-idr-second-best-backup is not yet available for
reading. I am certainly curious about whether and how it differs from
the add-paths draft -
http://tools.ietf.org/html/draft-walton-bgp-add-paths-05

Cheers,
Rajiv 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian Dickson
> Sent: Tuesday, February 05, 2008 6:47 PM
> Cc: [email-masked]
> Subject: [Idr] New ID and request for time slot
> 
> > A new version of I-D, 
> draft-dickson-idr-second-best-backup-00.txt has

---

From: Brian Dickson <[email-masked]>
Date: Tue, 05 Feb 2008 19:52:47 -0500

Rajiv Asati (rajiva) wrote:
> reading. 
Here's the link to the -00 version:
http://www.ietf.org/internet-drafts/draft-dickson-idr-second-best-backup-00.txt
> I am certainly curious about whether and how it differs from
> the add-paths draft -
Well, a quick review of add-paths seems to indicate several important 
differences:
- add-paths appears limited in scope to route-reflectors, but does so 
very well
- second-best-backup focuses more on inter-AS effects and direct 
intra-AS behavior

I expect that the two would in fact complement each other very effectively.

How exactly they would/could be merged may not be obvious just yet, but 
I don't see
any fundamental hurdles.

Certainly, it points to lots of things there that I will likely need to 
include in subsequent versions,
such as IANA considerations, references, etc. :-)

Thanks for pointing it out, I hadn't seen it before now.

Brian
>>> Title:           Enhanced BGP Capabilities for Exchanging 
>>>       
>> Second-best 
>>     
>>> and Back-up Paths

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 05 Feb 2008 23:35:05 -0800

Hi Brian,

Thx for the pointer to your draft.

It seems to me that draft-walton when combined with simply sending best 
external path (the latter some bgp implementations already support 
today) when IBGP learned path wins as the best do address all problems 
you are listing in section 1.

Could you point out what would be missing provided one would use above 
tools without additional capabilities or without need to modify bgp best 
path selection algorithm ?

Thx,
R.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 06 Feb 2008 05:20:20 -0800

Brian,

> I'd respectfully request a slot in Philly to present this material.

Sure. Just let Sue and myself how much time would you like for
your presentation.

Yakov.