Subject: [Idr] Comments on RFC4893

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 31 Jan 2008 18:46:10 -0800

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 ]

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.

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?

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. 

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.

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 ?

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 ?

IMHO, the above NOTIFICATION is helpful for transition phase.

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

---

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Thu, 31 Jan 2008 20:15:53 -0800

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:

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

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

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:

The above rule is confusing from the implementation perspective. How
about
making it simple by doing the same thing as AS_AGGREGATOR (as follows) ?

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.