[Idr] Comments on RFC4893

["Samita Chakrabarti" <[e-mail]>]

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
[e-mail]
http://www.ietf.org/mailman/listinfo/idr
From [e-mail]  Thu Jan 31 18:56:59 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 93BC028C170;
	Thu, 31 Jan 2008 18:56:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0FngcvYpdBbM; Thu, 31 Jan 2008 18:56:58 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5EBCB28C101;
	Thu, 31 Jan 2008 18:56:58 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3E34E28C0FD
	for <[e-mail]>; Thu, 31 Jan 2008 18:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 36i884-6u1+A for <[e-mail]>;
	Thu, 31 Jan 2008 18:56:56 -0800 (PST)
Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.244])
	by core3.amsl.com (Postfix) with ESMTP id 0D53828C101
	for <[e-mail]>; Thu, 31 Jan 2008 18:56:55 -0800 (PST)
Received: by hs-out-2122.google.com with SMTP id 54so792522hsz.5
	for <[e-mail]>; Thu, 31 Jan 2008 18:58:29 -0800 (PST)
Received: by 10.142.252.11 with SMTP id z11mr1832373wfh.50.1201834708678;
	Thu, 31 Jan 2008 18:58:28 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Thu, 31 Jan 2008 18:58:28 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 31 Jan 2008 18:58:28 -0800
From: "Vishwas Manral" <[e-mail]>
To: idr <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Subject: [Idr] Fwd: 6PE-Alt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/idr>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/idr>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Forwarding from the discussion on the v6ops list - on the draft.

---------- Forwarded message ----------
From: Vishwas Manral <[e-mail]>
Date: Jan 31, 2008 3:46 PM
Subject: Re: 6PE-Alt
To: DE CLERCQ Jeremy <[e-mail]>
Cc: Francois Le Faucheur IMAP <[e-mail]>,
[e-mail], Ooms Dirk <[e-mail]>,
[e-mail]


Hi Jeremy,

You are absolutely right.

This is not an alternate mechanism it is just an interesting way of
using already existing functionality BGP-IPv6 to derive the same
functionality as 6PE. We can get 6PE functionality without having to
do any different signaling at all.

It saves all the complicated mechanisms of label distribution, label
signaling, defining AFI/ SAFI and the complicated Inter-AS
distribution to achieve the same functionality. We do not need to
populate the hardware either with that many entries. I think that is
the idea of the draft.

Thanks,
Vishwas

On Jan 31, 2008 3:41 PM, DE CLERCQ Jeremy

<[e-mail]> wrote:
> Hi Vishwas,
>
> Aha. Now I see; I got carried away by the discussion instead of looking
> at the draft ;).
>
> So the question remains whether the possible benefits of this solution
> justify bringing another alternative approach solving the same problem
> into the standards.
>
>
> Regards,
> Jeremy.
>
> >
> > Hi Jeremy,
> >
> > I agree a single level of label should not be used. The 6PE RFC
> > clearly talks about reasons for the same in great detail.
> >
> > That option should not be used and I agree to it. However the 6PE-Alt
> > approach uses 2 level of labels. The inner label is the Explicit NULL
> > label and the outer label is the tunnel label which gets the packet
> > from one 6Pe router to the other. The document below clearly misses
> > the idea of using a predefined label as the tunnel label.
> >
> > I hope things are clearer now to you.
> >
> > Thanks,
> > Vishwas
> >
> > On Jan 31, 2008 2:07 PM, DE CLERCQ Jeremy
> > <[e-mail]> wrote:
> > > Hi Vishwas,
> > >
> > > I was refering to e.g. section 6.2 in
> > > draft-ietf-ngtrans-bgp-tunnel-02.txt, where it says
> > >
> > > "
> > > Where a single level of label is used and no label are advertised by
> > > MP-BGP, the SAFI used in MP-BGP will be one of the basic values:
> > > unicast, multicast or both (1,2 or 3).
> > > "
> > >
> > > With regards to the reason why the labelled approach was finally
> > > selected: it had to do on one hand with the main
> > applicability of the
> > > approach for routers that typically do labelled BGP distribution for
> > > VPNs, and on the other hand with the fact that the
> > advantages of using
> > > labelled distribution seemed to outweigh the disadvantages
> > like memory
> > > requirements etc.
> > >
> > > With regards to interoperability, what I meant was that it
> > was deemed
> > > better to have not too many optional and alternative
> > solutions in one
> > > RFC and to limit it to the chosen approach.
> > >
> > > Regards,
> > > Jeremy.
> > >
> > >
> > >
> > > > Hi Jeremy,
> > > >
> > > > I did look at the draft-ietf-ngtrans-bgp-tunnel-02.txt. I
> > could not
> > > > find a mention of the mechanism I have mentioned. Could you please
> > > > point me to the place where the mechanism is mentioned?
> > > >
> > > > BTW, the simple mechanism you talk about, adds a AFI/ SAFI pair to
> > > > BGP, unnecessarily passes labels around which are not
> > used at all. It
> > > > increases the memory requirement of each route, increases
> > the size of
> > > > the serach key and has complicated Transit provider
> > mechanisms. It in
> > > > turn clutters the forwarding tables with data which could
> > be easily
> > > > done without. The interesting part is the same could be
> > done without
> > > > any extensions at all.
> > > >
> > > > You seem to say that due to some interoperability
> > concerns you added
> > > > the mechanism to explicitly signal labels, which serve no
> > purpose. Can
> > > > you let me know which implementations had
> > interoperability concerns?
> > > > It would be great if you can give a more exact technical
> > reason of why
> > > > the approach we intend to bring to the IETF (which by default is
> > > > inter-operable - as no extensions are required). It is
> > hard to for a
> > > > person who has not been through the entire history to
> > understand the
> > > > same.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > On Jan 31, 2008 12:56 PM, DE CLERCQ Jeremy
> > > > <[e-mail]> wrote:
> > > > > Hi Vishwas,
> > > > >
> > > > > > I however am surprised how
> > > > > > this simple mechanism was not captured earlier in the
> > > > review or coding
> > > > > > process.
> > > > >
> > > > > The work that lead to what is now known as 6PE has seen
> > > > many forms and
> > > > > many many iterations. Including approaches without label
> > > > signaling and
> > > > > allocation, even including approaches without MPLS. You
> > > > should be able
> > > > > to find out about this history via earlier versions of the
> > > > draft like
> > > > > draft-nguyen-ngtrans-bgp-tunnel-00.txt and
> > > > > draft-ietf-ngtrans-bgp-tunnel-02.txt.
> > > > >
> > > > > So I'd say that this simple mechanism was captured earlier
> > > > but that it
> > > > > has been decided not to retain it, and to keep only one
> > mandatory
> > > > > procedure for interoperability purposes.
> > > > >
> > > > > At the end it was working group consensus and interoperable
> > > > > implementations that lead to the current 6PE approach.
> > > > >
> > > > > Regards,
> > > > > Jeremy
> > > > >
> > > >
> > >
> >
>
_______________________________________________
Idr mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/idr
From [e-mail]  Thu Jan 31 20:15:05 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0B4D128C187;
	Thu, 31 Jan 2008 20:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,
	BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id aXbsXre-Y4yy; Thu, 31 Jan 2008 20:15:03 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6AB0928C13D;
	Thu, 31 Jan 2008 20:15:03 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B10D528C13D
	for <[e-mail]>; Thu, 31 Jan 2008 20:15:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id RMvP9ZDg6nDB for <[e-mail]>;
	Thu, 31 Jan 2008 20:15:00 -0800 (PST)
Received: from mx.force10networks.com (corp.force10networks.com
	[64.186.164.204])
	by core3.amsl.com (Postfix) with ESMTP id 7E82528C0F0
	for <[e-mail]>; Thu, 31 Jan 2008 20:15:00 -0800 (PST)
Received: from EXCH-CLUSTER-03.force10networks.com ([10.11.0.53]) by
	mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 31 Jan 2008 20:15:57 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jan 2008 20:15:53 -0800
Message-ID: <[e-mail]>
In-Reply-To: <002f01c8647c$9dafb700$9d000a0a@samitacD600>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] Comments on RFC4893
Thread-Index: AchkfJnFg0bX62edRpC+ThO14/0EDgAB9ayQ
References: <002f01c8647c$9dafb700$9d000a0a@samitacD600>
From: "Kalpesh Zinjuwadia" <[e-mail]>
To: "Samita Chakrabarti" <[e-mail]>, <[e-mail]>,
	<[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 01 Feb 2008 04:15:57.0348 (UTC)
	FILETIME=[24F65640:01C86489]
Subject: Re: [Idr] Comments on RFC4893
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/idr>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/idr>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Some comments inline.

Thanks,
Kalpesh

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Samita Chakrabarti
Sent: Thursday, January 31, 2008 6:46 PM
To: [e-mail]; [e-mail]; [e-mail]
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
[e-mail]
http://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/idr