Re: [v6ops] [Idr] BGP Identifier

"Fan, Peng" <fanpeng@chinamobile.com> Tue, 18 February 2014 06:08 UTC

Return-Path: <fanpeng@chinamobile.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8121A05FD; Mon, 17 Feb 2014 22:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.226
X-Spam-Level:
X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GoVOyozubEa; Mon, 17 Feb 2014 22:08:22 -0800 (PST)
Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A58CC1A03E7; Mon, 17 Feb 2014 22:08:21 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302f84b6ad-f66ad; Tue, 18 Feb 2014 14:06:03 +0800 (CST)
X-RM-TRANSID: 2ee15302f84b6ad-f66ad
Received: from X6X8D79D8F49E2 (unknown[10.2.43.104]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee25302f84b837-f786b; Tue, 18 Feb 2014 14:06:03 +0800 (CST)
X-RM-TRANSID: 2ee25302f84b837-f786b
From: "Fan, Peng" <fanpeng@chinamobile.com>
To: "'Christopher Morrow'" <morrowc.lists@gmail.com>
References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <m2iosdta7m.wl%randy@psg.com> <2014021811305909988540@chinamobile.com> <CAL9jLaa6fXL+FFNFgdK257dbHGXqm4YBRfMEocoQPEAczPmH-Q@mail.gmail.com>
In-Reply-To: <CAL9jLaa6fXL+FFNFgdK257dbHGXqm4YBRfMEocoQPEAczPmH-Q@mail.gmail.com>
Date: Tue, 18 Feb 2014 14:09:30 +0800
Message-ID: <00dc01cf2c6f$fcce3c40$f66ab4c0$@chinamobile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QKQBeNnAdstUIkBXjGXJpkRA7Iw
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IupipvShwk07h9Jb4-SJc10E5og
Cc: 'idr wg' <idr@ietf.org>, 'V6 Ops List' <v6ops@ietf.org>
Subject: Re: [v6ops] [Idr] BGP Identifier
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 06:08:26 -0000

Hi Christopher,

Normally it is easier to handle routers within the AS as we have full
control over it. I think the key point is the ASBR, as we have no control of
its eBGP peers. A simple approach is to enable both this extension and
RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup
purpose before we are aware of the capability of its peers. The ASBR prefers
the 128-bit ID. Since the ID field of OPEN message sent by the ASBR is zero,
which will result in a "bad bgp identifier" error message sent by the peer
if it does not support the new 128-bit ID capability, the ASBR will know the
type of its peer. The ASBR can initiate a second connection in the old way,
and the connection falls back using 32-bit ID.

Peng

> -----Original Message-----
> From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com]
> On Behalf Of Christopher Morrow
> Sent: Tuesday, February 18, 2014 11:42 AM
> To: lizhenqiang@chinamobile.com
> Cc: Randy Bush; Farmer; jaeggli; Amante; JAMES; Doering; Raszuk'; fanpeng;
idr
> wg; V6 Ops List
> Subject: Re: Re: [Idr] [v6ops] BGP Identifier
> 
> On Mon, Feb 17, 2014 at 10:30 PM, lizhenqiang@chinamobile.com
> <lizhenqiang@chinamobile.com> wrote:
> > Hi All,
> >
> > Thank you all for your valuable comments and interests in this draft.
> > Any technical concerns about the draft? Is there someone in the mail
> > list from operators that has the same problem as me?
> >
> 
> i think shane's point about 'make a stab at transition technique'
> still needs to be dealt with, yes?
> 
> and really... I don't see a huge reason to do this anyway, yet.
> 
> > Many Thanks,
> > Zhenqiang Li
> >
> > ________________________________
> >