Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 06 November 2020 02:50 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1673A0656 for <idr@ietfa.amsl.com>; Thu, 5 Nov 2020 18:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xTam30cxOevV for <idr@ietfa.amsl.com>; Thu, 5 Nov 2020 18:50:09 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8433A0115 for <idr@ietf.org>; Thu, 5 Nov 2020 18:50:08 -0800 (PST)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CS4b65PKHz67HMJ for <idr@ietf.org>; Fri, 6 Nov 2020 10:48:50 +0800 (CST)
Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 6 Nov 2020 03:50:05 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 6 Nov 2020 10:50:03 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Fri, 6 Nov 2020 10:50:03 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)
Thread-Index: AdawxZFiqE7+Vp6ETxeuJxQP7/0gpQDHG6AA
Date: Fri, 06 Nov 2020 02:50:03 +0000
Message-ID: <90afe1f6a6ae4a8dbe35ae03b6549f2f@huawei.com>
References: <045d01d6b0c7$c5eb4900$51c1db00$@ndzh.com>
In-Reply-To: <045d01d6b0c7$c5eb4900$51c1db00$@ndzh.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.143]
Content-Type: multipart/alternative; boundary="_000_90afe1f6a6ae4a8dbe35ae03b6549f2fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DTdryk40thYtVC6aAGGqVoZ2Dvg>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2020 02:50:11 -0000

Hi,

Yes, support with one question for clarification:

For SRv6 EPE, the Peer adjacency SID is advertised using SRv6 End.X SID TLV with BGP-LS Link NLRI, and this document says:

"The SRv6 End.X SID for the BGP Peer Adjacency indicates the cross-connect to a specific layer-3 link to the specific BGP session peer (neighbor)."

For the SRv6 EPE Peer Node SID, this document says:

"... the similar Peer Node and Peer Set functionality can be realized with SRv6 using the END.X behavior. The SRv6 BGP Peer Node SID TLV is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI corresponding to BGP protocol."

My question is: for a BGP peer established using direct interface address, does this require both a peer adj-SID with BGP-LS Link NLRI and a peer node SID in SRv6 SID NLRI be advertised?  While with the mechanism of SR-MPLS EPE, my understanding is in this case advertising only the peer node SID would be enough, the peer adj-SID is optional and may be used for a multi-hop session with multiple underlying layer-3 links.

Best regards,
Jie

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 11:25 AM
To: idr@ietf.org
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

This begins an IPR call and a 2 week WG LC for
draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1 to 11/16/2020)

You can access the draft at:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/

This draft focus on the BGP-LS support for SRv6.
Spring has proposed the SRv6 support in RFC8402
(see section 3.1.3 for mechanisms and section 8.2 for
Security considerations).

There are two implementations: Cisco and GoBGP
You can see the implementation report at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

In your responses, please consider the following questions:
a) Is the SRv6 technology ready for deployment or
are there known issues?

b) Will SRv6 provide valuable support for
deployments of BGP-LS in support of source routing
(aka spring)?

c) Is this draft ready for publication?

If you know of additional implementations, please send
a note to the idr chairs with the information or
respond to this email.

Cheers, Susan Hares