Re: [Idr] 6PE-Alt draft

[Martin Horneffer <[e-mail]>]

Hi Vishwas,

just a quick question from an operator's point of view: what is your
consideration of how a P device (IPv4/MPLS only) should do the
load-sharing for 6PE traffic in case of ECMP?

If I got it correctly 6PE allows the egress PE to use different labels
which would make it easy for a P device to load-share. It does not
have to, though...

Best regards, Martin


On Thu, Jan 31, 2008 at 09:32:01AM -0800, Vishwas Manral wrote:
> Hi Jan,
> 
> Unlike in BGP MPLS IP VPN, the label does not tell any interface as we
> finally look up the only routing table the IPv6 routing table. We do
> not have the VRF concept here. That is the reason we do not need any
> presignaled label. The 6PE draft mentions why we need the top label
> very clearly.
> 
> However they have wrongly decided to signal a label with each route
> instead of just using the IPv6 Explicit NULL label.
> 
> Thanks,
> Vishwas
> 
> On Jan 31, 2008 9:00 AM, Jan Novak <[e-mail]> wrote:
> >
> >
> >
> > Hi Vishwas,
> >
> > I believe you refer to this part of 6PE spec:
> >
> >    The label bound by MP-BGP to the IPv6 prefix indicates to the egress
> >    6PE Router that the packet is an IPv6 packet.  This label advertised
> >    by the egress 6PE Router with MP-BGP MAY be an arbitrary label value,
> >    which identifies an IPv6 routing context or outgoing interface to
> >    send the packet to, or MAY be the IPv6 Explicit Null Label.  An
> >    ingress 6PE Router MUST be able to accept any such advertised label.
> >
> > I don't know what is the envisaged use of Explicit Null here - but I would think
> > it is for some other purposes since to deliver the packet to the VPN this is
> > still needed "identifies an IPv6 routing context or outgoing interface to".
> >
> > Jan
> >
> >
> >
> >
> > _________________________________________________________________
> > Share what Santa brought you
> > https://www.mycooluncool.com
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr

-- 
Dr. Martin Horneffer
T-Com Center Technology Engineering
Internet Backbone Architecture

Deutsche Telekom AG
Supervisory Board: Dr. Klaus Zumwinkel (Chairman)
Board of Management: René Obermann (Chairman),
Dr. Karl-Gerhard Eick (Deputy Chairman),
Hamid Akhavan, Timotheus Höttges, Thomas Sattelberger
Commercial register: Amtsgericht Bonn HRB 6794,
corporate seat: Bonn
WEEEreg.no: DE50478376
_______________________________________________
Idr mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/idr
From [e-mail]  Fri Feb  1 05:09:20 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 9F4D328D936
	for <[e-mail]>; Fri,  1 Feb 2008 05:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009,
	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 s0fExShNWOPS for <[e-mail]>;
	Fri,  1 Feb 2008 05:09:06 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0918428D939
	for <[e-mail]>; Fri,  1 Feb 2008 05:01:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: [e-mail]
To: [e-mail]
X-No-Archive: yes
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2008 05:00:49 -0800
Precedence: bulk
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
List-Id: <mailman.core3.amsl.com>
X-List-Administrivia: yes
Sender: [e-mail]
Errors-To: [e-mail]

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, [e-mail]) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

If you have questions, problems, comments, etc, send them to
[e-mail].  Thanks!

http://www.ietf.org/mailman/options/idr/idr-archive%40megatron.ietf.org
From [e-mail]  Fri Feb  1 05:09:41 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 3E51328CC3E
	for <[e-mail]>; Fri,  1 Feb 2008 05:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009,
	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 RKUZ3OTjds9E for <[e-mail]>;
	Fri,  1 Feb 2008 05:09:15 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 88D2B28C74E
	for <[e-mail]>; Fri,  1 Feb 2008 05:01:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: [e-mail]
To: [e-mail]
X-No-Archive: yes
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2008 05:00:50 -0800
Precedence: bulk
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
List-Id: <mailman.core3.amsl.com>
X-List-Administrivia: yes
Sender: [e-mail]
Errors-To: [e-mail]

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, [e-mail]) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

If you have questions, problems, comments, etc, send them to
[e-mail].  Thanks!

http://www.ietf.org/mailman/options/idr/idr-archive%40megatron.ietf.org
From [e-mail]  Fri Feb  1 09:27:15 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 B153C28C1B6;
	Fri,  1 Feb 2008 09:27:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level: 
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5
	tests=[AWL=-0.033, BAYES_00=-2.599, URIBL_RHS_DOB=1.083]
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 ybnEhKtPBPYO; Fri,  1 Feb 2008 09:27:14 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A1D5B3A68F6;
	Fri,  1 Feb 2008 09:27:14 -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 19C733A6882
	for <[e-mail]>; Fri,  1 Feb 2008 09:27:13 -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 i8iojqxLE6gi for <[e-mail]>;
	Fri,  1 Feb 2008 09:27:12 -0800 (PST)
Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.183])
	by core3.amsl.com (Postfix) with ESMTP id B386928C2CF
	for <[e-mail]>; Fri,  1 Feb 2008 09:25:04 -0800 (PST)
Received: by el-out-1112.google.com with SMTP id j27so607720elf.25
	for <[e-mail]>; Fri, 01 Feb 2008 09:26:39 -0800 (PST)
Received: by 10.142.52.9 with SMTP id z9mr2323818wfz.201.1201886798419;
	Fri, 01 Feb 2008 09:26:38 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Fri, 1 Feb 2008 09:26:38 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 1 Feb 2008 09:26:38 -0800
From: "Vishwas Manral" <[e-mail]>
To: "Martin Horneffer" <[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]>
Cc: [e-mail]
Subject: Re: [Idr] 6PE-Alt draft
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Errors-To: [e-mail]

Hi Martin,

The load sharing and everything else on the of P devices will still
work the same way. So we would have for example LDP running on the P
routers giving out labels for FEC's just the same way. The P device
works on the outer Tunnel label and its functionality will not change
in my view.

There is a case of having different labels for preventing one IPv6
lookup in some cases but in case we had the ECMP case we would have to
use the IPv6 header lookup and use the inner label as an IPv6 Explicit
NULL label.

Do let me know if I missed the point?

Thanks,
Vishwas

On Feb 1, 2008 1:07 AM, Martin Horneffer <[e-mail]> wrote:
> Hi Vishwas,
>
> just a quick question from an operator's point of view: what is your
> consideration of how a P device (IPv4/MPLS only) should do the
> load-sharing for 6PE traffic in case of ECMP?
>
> If I got it correctly 6PE allows the egress PE to use different labels
> which would make it easy for a P device to load-share. It does not
> have to, though...
>
> Best regards, Martin
>
>
>
> On Thu, Jan 31, 2008 at 09:32:01AM -0800, Vishwas Manral wrote:
> > Hi Jan,
> >
> > Unlike in BGP MPLS IP VPN, the label does not tell any interface as we
> > finally look up the only routing table the IPv6 routing table. We do
> > not have the VRF concept here. That is the reason we do not need any
> > presignaled label. The 6PE draft mentions why we need the top label
> > very clearly.
> >
> > However they have wrongly decided to signal a label with each route
> > instead of just using the IPv6 Explicit NULL label.
> >
> > Thanks,
> > Vishwas
> >
> > On Jan 31, 2008 9:00 AM, Jan Novak <[e-mail]> wrote:
> > >
> > >
> > >
> > > Hi Vishwas,
> > >
> > > I believe you refer to this part of 6PE spec:
> > >
> > >    The label bound by MP-BGP to the IPv6 prefix indicates to the egress
> > >    6PE Router that the packet is an IPv6 packet.  This label advertised
> > >    by the egress 6PE Router with MP-BGP MAY be an arbitrary label value,
> > >    which identifies an IPv6 routing context or outgoing interface to
> > >    send the packet to, or MAY be the IPv6 Explicit Null Label.  An
> > >    ingress 6PE Router MUST be able to accept any such advertised label.
> > >
> > > I don't know what is the envisaged use of Explicit Null here - but I would think
> > > it is for some other purposes since to deliver the packet to the VPN this is
> > > still needed "identifies an IPv6 routing context or outgoing interface to".
> > >
> > > Jan
> > >
> > >
> > >
> > >
> > > _________________________________________________________________
> > > Share what Santa brought you
> > > https://www.mycooluncool.com
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/idr
>
> --
> Dr. Martin Horneffer
> T-Com Center Technology Engineering
> Internet Backbone Architecture
>
> Deutsche Telekom AG
> Supervisory Board: Dr. Klaus Zumwinkel (Chairman)
> Board of Management: René Obermann (Chairman),
> Dr. Karl-Gerhard Eick (Deputy Chairman),
> Hamid Akhavan, Timotheus Höttges, Thomas Sattelberger
> Commercial register: Amtsgericht Bonn HRB 6794,
> corporate seat: Bonn
> WEEEreg.no: DE50478376
>
_______________________________________________
Idr mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/idr
From [e-mail]  Fri Feb  1 10:33:26 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 792BF3A6917;
	Fri,  1 Feb 2008 10:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level: 
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225,
	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 tO2GKi7KGYZo; Fri,  1 Feb 2008 10:33:25 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EC6A33A683D;
	Fri,  1 Feb 2008 10:33:24 -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 A36673A67B1
	for <[e-mail]>; Fri,  1 Feb 2008 10:33:23 -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 ydMM+HlmChY2 for <[e-mail]>;
	Fri,  1 Feb 2008 10:33:22 -0800 (PST)
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228])
	by core3.amsl.com (Postfix) with ESMTP id BE3553A68B1
	for <[e-mail]>; Fri,  1 Feb 2008 10:33:21 -0800 (PST)
Received: by wr-out-0506.google.com with SMTP id 50so1497983wri.25
	for <[e-mail]>; Fri, 01 Feb 2008 10:34:56 -0800 (PST)
Received: by 10.142.88.20 with SMTP id l20mr2412831wfb.72.1201890895199;
	Fri, 01 Feb 2008 10:34:55 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Fri, 1 Feb 2008 10:34:55 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 1 Feb 2008 10:34:55 -0800
From: "Vishwas Manral" <[e-mail]>
To: "Kalpesh Zinjuwadia" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
References: <002f01c8647c$9dafb700$9d000a0a@samitacD600>
	<[e-mail]>
Cc: [e-mail], [e-mail]
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]

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
<[e-mail]> wrote:
> 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
>
_______________________________________________
Idr mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/idr