Return-Path: 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 7B585120828; Fri, 1 Nov 2019 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=XJtVFzF5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tgHeat4P 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 U8U-STQDtMaT; Fri, 1 Nov 2019 13:05:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0796512008A; Fri, 1 Nov 2019 13:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54782; q=dns/txt; s=iport; t=1572638738; x=1573848338; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A/RUvTHJkXk72LL9KVLzh9ZYq8JyQKYPuhSuPQ7uMhQ=; b=XJtVFzF58rpHLDjrO1wcEU+XA6M7i+MZgWw1+lwzGhWM0igzpzpgv5iL yviZCY2vOKi+1URy/USeMYNEDQsU//J8zKWtk8q7IE3/Tkp5sfyG6Pn0+ VEGX61OKwpCXzLy3RBNrNrc3gMv1b53/yO0cKELxpeJ/fhD70Nm/rZhFm 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AWtEzqBZeOtbZ2lHaC9B84vj/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q6bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavpYjAzGthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAABOj7xd/49dJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgX2BHC8kLAVsWCAECyqEKINGA4p0gl6?= =?us-ascii?q?XfIFCgRADVAkBAQEMAQElCAIBAYRAAoN7JDgTAgMLAQEEAQEBAgEFBG2FNwy?= =?us-ascii?q?FUQEBAQEDDgQPAQsTAQEjDQcBDwIBCBEEAQEQEQEGAgMCMhQJCAEBBAENBQg?= =?us-ascii?q?agwGBeU0DLgEOlzOQYgKBOIhgcAGBNoJ+AQEFhRgYghcDBoE2jBEYgUA/gRE?= =?us-ascii?q?BRYJMPoJiAQECAYErARIBISsJglc1giyVOYVag1+OHGgKgiSHEY4/gjyHWo1?= =?us-ascii?q?ugWGOQIgukSYCBAIEBQIOAQEFgWkiZ3FwFYMnUBEUgwYMF4NQhRSDGYImdAG?= =?us-ascii?q?BJ4sUgjABAQ?= X-IronPort-AV: E=Sophos;i="5.68,256,1569283200"; d="scan'208,217";a="433840532" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 20:05:34 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1K5YwC010270 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 20:05:34 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 15:05:33 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 15:05:32 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 16:05:32 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ExRDEg0BBqgforY9rgZJVSYeKK+fklO3e27Hs/NS5gJM0/DHJXHkDpxtmpP1oGbwvrBB0yGzVJRqYwYc7EHm13EymY3hWQTwAyaMGRPN9cVMb2Yh3/cs5lr0bKaH+EF8f12cNBC48qu+4GpdGhLnID6nk3vZ1Zt6MpMwbOrWIISd0szuY7BJIKOkuvEwRU1txE5TYPiKHY+RKfmkjE7eGijpfKwBTB+NpGMklV3vri0sB2sobmZ5f5rAP40xLuFzJ86rahE/9JOwqweoD2Tygtkzd1HkJk4bQ5ezylH+rcMZo/zptLuPMx4QAXHPN1NK6DBKXl/cZIqDl0V8SYF1pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EHUFqfj3TQN6Wy0y/ABwMhFbJZSFUNSxIXlLZ21gj+8=; b=VcZTcyxg1Dn+xiYSk2dcEfXfSzVykS8aKuNWYIk7lAMZz21qm/6qMzdBhyfixECykzbGcDZnX4GePYoemH5A0E7S198dse5Sx6cOB4EeUZX2N7BifSNi5nIMCx0wHt83x000vG3iSyhMUl8kUiSkpVm41LvjjlnHV7Z8QSAwZS+yursemyGxBVUlhqw4LEvEGzlJTv1sIofmvlpVTBf7LA7emk0348XdJ+zbPHrQ+ybgqw68bPOoZNVZ3nka9NAQh+h6cFgLKLfNzInTQDvEf29g8yxoA4cVPPEa2zgcK/EeI3i8HRwFc205Vplu/i9MJuV7gAwPvskSavcgg6f7Zw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EHUFqfj3TQN6Wy0y/ABwMhFbJZSFUNSxIXlLZ21gj+8=; b=tgHeat4PATWJNY/aaL1seV7SCJYqNAu9RW44ypbGD5ku2R6vfPaY0tppQ4nPXrP73kkHYOCGnB2OGABXTky7FxToeDHtCnTK3YfkkjLwQ3Rk2ZmdOCD3egoIQVrI7cqAn7yrPvINUI/lNM7wf3Qv2HRYWn6ozLnYY0PxBKsEiv8= Received: from CY4PR11MB1541.namprd11.prod.outlook.com (10.172.68.150) by CY4PR11MB1767.namprd11.prod.outlook.com (10.175.61.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.18; Fri, 1 Nov 2019 20:05:31 +0000 Received: from CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::d3a:84a6:be65:e33f]) by CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::d3a:84a6:be65:e33f%11]) with mapi id 15.20.2387.028; Fri, 1 Nov 2019 20:05:31 +0000 From: "Ketan Talaulikar (ketant)" To: "Wanghaibo (Rainsword)" , "draft-ietf-idr-bgpls-srv6-ext@ietf.org" CC: "idr@ietf.org" Thread-Topic: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext Thread-Index: AdVMOJt7jNPQrPmHQpm89zff5sqK1qb23+LAgDc+vnCmpLPpIA== Date: Fri, 1 Nov 2019 20:05:30 +0000 Message-ID: References: <1E61161D6E31D849BEA887261DB609348C8DDD73@nkgeml514-mbs.china.huawei.com> <1E61161D6E31D849BEA887261DB609348C935798@nkgeml514-mbx.china.huawei.com> In-Reply-To: <1E61161D6E31D849BEA887261DB609348C935798@nkgeml514-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com; x-originating-ip: [2405:201:1800:c766:3561:9fe4:5e7b:45f6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3dc9a93c-a239-478c-ec3c-08d75f06d902 x-ms-traffictypediagnostic: CY4PR11MB1767: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(396003)(346002)(39860400002)(376002)(199004)(189003)(6246003)(66574012)(7696005)(6506007)(52536014)(74316002)(4743002)(478600001)(2501003)(11346002)(46003)(486006)(5660300002)(99286004)(229853002)(86362001)(476003)(55016002)(236005)(76176011)(53546011)(9686003)(54896002)(186003)(6306002)(6436002)(110136005)(606006)(9326002)(316002)(6116002)(81166006)(71190400001)(81156014)(2906002)(790700001)(25786009)(7736002)(966005)(446003)(561944003)(71200400001)(256004)(102836004)(76116006)(14454004)(64756008)(66476007)(66556008)(66946007)(66446008)(4326008)(8936002)(8676002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1767; H:CY4PR11MB1541.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SE9h4O7oOPi6y4Ujv2ouoStl38nqS+EfXylK20jo3iIwynu+T9RTlXcWIx9F3/tiQNcaZHOFzQkQR1huzWm+zhmdFNy/Z3HRkCduWGDxtdTfGX6x7kL8HaBnJfvTTF6/9Eho/vqIF9whWUJpiIdmbJIfj1rFraJG8X1TXyQtiMTdpxu1xtsDPqoWaf6Wwch02VcIjmEzN1ziCNCUL3I3Cpue/bWeQqa5f4f4fIksETPCMJ57VvJfk3eLj6IMMS6+/9RC11r7dDS+ahw9KOI5/Y9oyLGDzS3of+03xhBpnpYQ6c3M1qxthM88CJG4SLnhjTNN+JiFkVfGfXYECJQKBtiMYcn7Q/ampNwuOm2odFJeCNc1pNN8fiO/72CvJ/KbQT157RK22Chl6lXOmdlAa7svhCsLN42POa5FqEaDy2cehrTwC9qSbio5ChgNl1IB8EO5/SbwFznILaxroU76iHxcab11ir94YOxYAs8kZVc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR11MB1541C5879E31284C683E1DB8C1620CY4PR11MB1541namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3dc9a93c-a239-478c-ec3c-08d75f06d902 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 20:05:30.9165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YLFPsFj07HAViNefRPnGPZs11MQ2zjYFNi/JfUmDUZmzjq9mlu5TjNmz/54ddZxG+7j+B95j7PwvseEE88tRbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1767 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Idr] [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 20:05:42 -0000 --_000_CY4PR11MB1541C5879E31284C683E1DB8C1620CY4PR11MB1541namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Haibo, My apologies since I seem to have missed responding to your email below. Pl= ease check inline below. From: Wanghaibo (Rainsword) Sent: 16 September 2019 13:11 To: Ketan Talaulikar (ketant) ; draft-ietf-idr-bgpls-srv6= -ext@ietf.org Cc: idr@ietf.org Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext Hi Ketan, Can you give explanation for my last question. Thanks, Haibo From: Wanghaibo (Rainsword) Sent: Monday, August 12, 2019 11:54 AM To: 'Ketan Talaulikar (ketant)' >= ; draft-ietf-idr-bgpls-srv6-ext@ietf.org Cc: idr@ietf.org Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext Hi Ketan, Thanks for your reply. Your explanation is very clear, but there is still a little doubt. 1. In this usage, when we create EPE for a single-hop neighbor, we must = create two routes , one for the SRv6 SID NLRI and another for the Link NLR= I. In the previous method, we only need to report a PeerNode link NLRI [KT] Actually, we would still have two NLRIs since the descriptors for Peer= Adj SID is different from PeerNode SID as per the BGP-LS EPE draft. 1. In this new definition, a PeerSet may carry a large amount of Peer No= de SID TLV, and it may cause the message to be too large. [KT] Not really. It is just 16 byte per peer in the PeerSet. Also, when a p= acket with received with a PeerSet SID in the DA, what we need to do is loa= d-balance across all Peers in that set. So I feel it more closely maps into= the forwarding state as well. In this way, the whole numbers NLRI will increase. [KT] The main idea was to use the Link NLRI to describe the actual link in = the link-state topology and not for the Peering session which may be single= hop or multi-hop and may map to multiple underlying links/paths. If it is multi-hop neighbors and all have joined to PeerSets, the number of= routes added is equivalent to the number of PeerSets. If it is single neighbor and all have joined to PeerSets, the number of add= ed routes is equivalent to the number of neighbors plus the number of PeerS= ets. [KT] If you see the NLRIs now more closely resemble the forwarding state on= the router. So whether we have more NLRIs or less would dependent on how t= he sets are organized and we should consider the normal and not the worst t= heoretical case. Do we have to support both options at the same time, or do we only use the = one described now? [KT] Not sure I follow what options you are referring to, but we can surely= discuss perhaps in Singapore. Thanks, Ketan Thanks, Haibozuo From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, August 09, 2019 2:14 AM To: Wanghaibo (Rainsword) >; draft-ietf-idr-bgpls-srv6-ext@ietf.org Cc: idr@ietf.org Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext Hi Haibo, Thanks for your review and your comments. The draft proposal for how EPE SI= Ds are signalled for SRv6 do differ from how they are done for SR/MPLS. Thi= s change is based on our implementation and deployment experience - there w= as a potential to simplify the signalling of EPE SIDs for SRv6. In a nutshell, the proposal is as follows: 1. PeerAdj SID is associated with an underlying interface to the connect= ed peer. In almost every sense, it is similar to the IGP Adjacency SID. Hen= ce, the SRv6 End.X SID TLV is used to advertise it (associated with Link NL= RI) similar to how it=1B$B!G=1B(Bs done for PeerAdj SID for SR/MPLS. This p= art you have no issue/doubt about. 2. For the PeerNode and the PeerSet SIDs, in SR/MPLS case we created ano= ther BGP-LS Link NLRI that is separate from the one created for PeerAdj SID= . This is because the link descriptors are different. They may be same or m= ay not be same depending on whether the session is single-hop (i.e. using i= nterface addresses for peering) or multi-hop (e.g. using loopback addresses= for peering). Note in https://tools.ietf.org/html/draft-ietf-idr-bgpls-seg= ment-routing-epe-19#section-4.2 that use of link local/remote IDs are MUST = for PeerAdj SID but may not be available for the PeerNode SID for a multi-h= op session. This new/additional Link NLRI for the signalling of PeerNode and PeerSet SI= Ds is avoidable. With SRv6, we have just a single PeerNode SID which is advertised as a SID = associated with the Node. The SRv6 BGP Peer Node SID TLV indicates the remo= te peer information. So it will become: NLRI : SRv6 SID NLRI1 (local node desc + SID1) and with it in BGP-LS Attri= bute : Peer Node SID TLV (peer1) NLRI : SRv6 SID NLRI2 (local node desc + SID2) and with it in BGP-LS Attri= bute : Peer Node SID TLV (peer2) Now, for the PeerSet SID, it is actually the same SID that is associated wi= th multiple peers. This can be signalled using the same SRv6 BGP Peer Node = SID TLV with the S flag set. So for a shared Set SID between two peers, it = will become: NLRI : SRv6 SID NLRI3 (local node desc + SID3) and with it in BGP-LS Attrib= ute : Peer Node SID TLV (peer 1 + Sflag=3Dset), Peer Node SID TLV (peer 2 += Sflag=3Dset) This seems more simpler and intuitive because we describing the SID and not= mixing it up with links in a link-state topology representation. The other alternative approach was to also advertise the SRv6 BGP Peer Node= SID TLV along with the Link NLRI advertised for the End.X SID TLV correspo= nding to the PeerAdj SID without requiring additional Link NLRIs (with diff= erent descriptors) for the PeerNode and PeerSet SIDs. I hope this clarifies and explains the reason for departure from EPE signal= ling done for SR/MPLS. Feedback/suggestions are welcome. Thanks, Ketan From: Wanghaibo (Rainsword) > Sent: 06 August 2019 15:43 To: draft-ietf-idr-bgpls-srv6-ext@ietf.org Cc: idr@ietf.org Subject: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext Hi authors, I have some questions about this draft, comment with blue words. 2. BGP-LS Extensions for SRv6 o SRv6 End.X SID of the link state routing adjacency or the BGP EPE Peer Adjacency is advertised via a new SRv6 End.X SID TLV // No doubt about this o The BGP EPE Peer Node and Peer Set SID context is advertised via a new SRv6 BGP EPE Peer Node SID TLV // Here use a new TLV to descripe peer node & peer set 7.2. SRv6 BGP Peer Node SID TLV The BGP Peer Node SID and Peer Set SID for SR with MPLS dataplane are specified in [I-D.ietf-idr-bgpls-segment-routing-epe]. The similar Peer Node and Peer Set SID functionality can be realized with SRv6 using the END.X SRv6 SID. 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. This TLV MUST be included along with SRv6 End.X SID that is associated with the BGP Peer Node or Peer Set functionality. // Here said the peer node sid followed by the SRv6 SID NLRI 6. SRv6 SID NLRI A new "Link-State NLRI Type" is defined for SRv6 SID information as following: o Link-State NLRI Type: SRv6 SID NLRI (value TBD see IANA Considerations Section 8.1). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | Local Node Descriptors (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 SID Descriptors (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: SRv6 SID NLRI Format // Here defined the SRv6 SID NLRI. If we use this NLRI, when we have m= ore than one peer node, We may construct routes with: Route1: SRv6 SID NLRI1 (Local Node Desc + SID1) + Peer Node SID (peer1) = + other Attr Tlv Route2: SRv6 SID NLRI2 (Local Node Desc + SID2) + Peer Node SID (peer2) = + other Attr Tlv Why do we have to change to this? What are the benefits of this change? For draft draft-ietf-idr-bgpls-segment-routing-epe, the route will be Route1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) + ot= her Attr Tlv Route2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) + ot= her Attr Tlv Also in this format, when a peer join a peer set, how to create the ro= ute? Perhaps=1B$B!'=1B(B Route1: SRv6 SID NLRI1 (Local Node Desc + SID1) + Peer Node SID (peer1) = + other Attr Tlv Route2: SRv6 SID NLRI1 (Local Node Desc + SID2) + Peer Node SID (S-flag)= + other Attr Tlv What=1B$B!G=1B(Bs the relationship about the two routes ? If there exist a route3: Route3: SRv6 SID NLRI1 (Local Node Desc + SID3) + Peer Node SID (S-flag)= + other Attr Tlv Now the Peer node route1 belongs to route2=1B$B!G=1B(Bs Peer Set or rout= e3=1B$B!G=1B(Bs Peer Set? But it=1B$B!G=1B(Bs clear for old mpls epe draft: Route1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) + Pe= er Set Sid(set1)+other Attr Tlv Route2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) + Pe= er Set Sid(set1)+ other Attr Tlv Best Regards Haibo --_000_CY4PR11MB1541C5879E31284C683E1DB8C1620CY4PR11MB1541namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Haibo,

 

My apologies since I seem to have missed responding to your email b= elow. Please check inline below.

 

From: Wanghaibo (Rainsword) <rainsword.wang@huaw= ei.com>
Sent: 16 September 2019 13:11
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; draft-ietf-i= dr-bgpls-srv6-ext@ietf.org
Cc: idr@ietf.org
Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext=

 =

Hi Ketan,

 

     &nb= sp; Can you give explanation for my last question.

 

Thanks,

  Haibo

 

From: Wanghaibo (Rainsword)
Sent: Monday, August 12, 2019 11:54 AM
To: 'Ketan Talaulikar (ketant)' <ketant@cisco.com>; draft-ietf-idr-bg= pls-srv6-ext@ietf.org
Cc: idr@ietf.org
Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext=

 

Hi Ketan,

 

  Thanks for your reply.

  

  Your explanation is v= ery clear, but there is still a little doubt.

  1. In this usage, when we create EPE for a single-hop neighbor, we must= create two routes , one for the SRv6 SID NLRI  and another for the Li= nk NLRI. 

     &nb= sp;  In the previous method, we only need to report a PeerNode li= nk NLRI

[KT] Actually, we would still have two NLRIs since the descriptors for Pe= erAdj SID is different from PeerNode SID as per the BGP-LS EPE draft.<= /o:p>

 

  1. In this new definition, a PeerSet may carry a large amount of Peer N= ode SID TLV, and it may cause the message to be too large.

[KT] Not really. It is just 16 byte per peer in the PeerSet. Also, when a= packet with received with a PeerSet SID in the DA, what we need to do is l= oad-balance across all Peers in that set. So I feel it more closely maps into the forwarding state as well.

=  

 

In th= is way, the whole numbers NLRI will increase.

[KT] The main idea was to use the Link NLRI to describe the actual link i= n the link-state topology and not for the Peering session which may be sing= le hop or multi-hop and may map to multiple underlying links/paths.

If it= is multi-hop neighbors and all have joined to PeerSets, the number of rout= es added is equivalent to the number of PeerSets.

If it= is single neighbor and all have joined to PeerSets, the number of added ro= utes is equivalent to the number of neighbors plus the number of PeerSets.

[KT] If you see the NLRIs now more closely resemble the forwarding state = on the router. So whether we have more NLRIs or less would dependent on how= the sets are organized and we should consider the normal and not the worst theoretical case.

=  

Do we= have to support both options at the same time, or do we only use the one d= escribed now?

[KT] Not sure I follow what options you are referring to, but we can sure= ly discuss perhaps in Singapore.

 

Thanks,

Ketan=

=  

Thanks,

Haibozuo

 

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Friday, August 09, 2019 2:14 AM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>; draft-ietf-idr-bg= pls-srv6-ext@ietf.org
Cc: idr@ietf.org
Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext=

 

Hi Haibo,

 

Thanks for your review and your comments. The draft proposal for ho= w EPE SIDs are signalled for SRv6 do differ from how they are done for SR/M= PLS. This change is based on our implementation and deployment experience – there was a potential to simplify the si= gnalling of EPE SIDs for SRv6.

 

In a nutshell, the proposal is as follows:

 

  1. PeerAdj SID is associated with a= n underlying interface to the connected peer. In almost every sense, it is = similar to the IGP Adjacency SID. Hence, the SRv6 End.X SID TLV is used to advertise it (associated with Link NLRI)= similar to how it=1B$B!G=1B(Bs done for PeerAdj SID for SR/MPLS. This part= you have no issue/doubt about.
  2. For the PeerNode and the PeerSet SIDs, in SR/MPLS cas= e we created another BGP-LS Link NLRI that is separate from the one created= for PeerAdj SID. This is because the link descriptors are different. They may be same or ma= y not be same depending on whether the session is single-hop (i.e. using in= terface addresses for peering) or multi-hop (e.g. using loopback addresses = for peering). Note in https://tools.ietf.org/html/draft-ietf-idr-bgpl= s-segment-routing-epe-19#section-4.2 that use of link local/remote IDs = are MUST for PeerAdj SID but may not be available f= or the PeerNode SID for a multi-hop session.

 

This new/additional Link NLRI for the signalling of PeerNode and Pe= erSet SIDs is avoidable.

 

With SRv6, we have just a single PeerNode SID which is advertised a= s a SID associated with the Node. The SRv6 BGP Peer Node SID TLV indicates = the remote peer information. So it will become:

NLRI : SRv6 SID NLRI1 (local node desc + SID1)  and with i= t in BGP-LS Attribute : Peer Node SID TLV (peer1)

NLRI : SRv6 SID NLRI2 (local node desc + SID2)  and with i= t in BGP-LS Attribute : Peer Node SID TLV (peer2)

 

Now, for the PeerSet SID, it is actually the same SID that is assoc= iated with multiple peers. This can be signalled using the same SRv6 BGP Pe= er Node SID TLV with the S flag set. So for a shared Set SID between two peers, it will become:

NLRI : SRv6 SID NLRI3 (local node desc + SID3) and with it in B= GP-LS Attribute : Peer Node SID TLV (peer 1 + Sflag=3Dset), Peer Node S= ID TLV (peer 2 + Sflag=3Dset)

 

This seems more simpler and intuitive because we describing the SID= and not mixing it up with links in a link-state topology representation.

 

The other alternative approach was to also advertise the SRv6 BGP P= eer Node SID TLV along with the Link NLRI advertised for the End.X SID TLV = corresponding to the PeerAdj SID without requiring additional Link NLRIs (with different descriptors) for the PeerN= ode and PeerSet SIDs.

 

I hope this clarifies and explains the reason for departure from EP= E signalling done for SR/MPLS.

 

Feedback/suggestions are welcome.

 

Thanks,

Ketan

 

From: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
Sent: 06 August 2019 15:43
To: draft-= ietf-idr-bgpls-srv6-ext@ietf.org
Cc: idr@ietf.org
Subject: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext

 =

Hi authors,=

  &nbs= p;  I have some questions about this draft, comment with blue words.

 
2.  BGP-LS Extensions for SRv6
   o  SRv6 End.X SID of the link state routing adja=
cency or the BGP EPE
      Peer Adjacency is advertised via a =
new SRv6 End.X SID TLV

// No doubt about this=

 =   o  The BGP EPE Peer Node and Peer Set SID context is advertised= via a

 =      new SRv6 BGP EPE Peer Node SID TLV

// Here use a new TLV to descripe= peer node & peer set

 

7.2.  SRv6 BGP Peer Node SID TLV
   The BGP Peer Node SID and Peer Set SID for SR with MP=
LS dataplane are
   specified in [I-D.ietf-idr-bgpls-segment-routing-epe]=
.  The similar
   Peer Node and Peer Set SID functionality can be reali=
zed with SRv6
   using the END.X SRv6 SID.  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.=
  This TLV MUST be included along with
   SRv6 End.X SID that is associated with the BGP Peer N=
ode or Peer Set
   functionality.

// Here said the peer node sid fo= llowed by the SRv6 SID NLRI

 

6.  SRv6 SID NLRI
 
   A new "Link-State NLRI Type" is defined for=
 SRv6 SID information as
   following:
 
   o  Link-State NLRI Type: SRv6 SID NLRI (value TB=
D see IANA
      Considerations Section 8.1).

 

     0      &nbs=
p;            1 =
;            &n=
bsp;     2       &nb=
sp;           3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=
 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+=
-+
    |  Protocol-ID  |

    +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=



    |       &nbs=
p;            &=
nbsp;   Identifier        =
;            &n=
bsp;        |


    |        &nb=
sp;            =
   (64 bits)        =
            &nb=
sp;         |

    ++-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+|=



    |       &nbs=
p;       Local Node Descriptors (variable)&nb=
sp;            =
 //


    +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=



    |       &nbs=
p;       SRv6 SID Descriptors (variable) =
;            &n=
bsp;  //


    +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=



 


 


           =
           Figure 11: SRv=
6 SID NLRI Format


  &n=
bsp;  //
Here defined the SRv6 SID NLRI=
. If we use this NLRI, when we have more than one peer node,


   W=
e may construct routes with:


   R=
oute1: SRv6 SID NLRI1 (Local Node Desc + SID1) + Peer Node SID (pee=
r1) + other Attr Tlv


   R=
oute2: SRv6 SID NLRI2 (Local Node Desc + SID2) + Peer Node SID (pee=
r2) + other Attr Tlv


   W=
hy do we have to change to this?
What are the benefits of this =
change?


 


   F=
or draft draft-ietf-idr-bgpls-segment-routing-epe, the route will be


   R=
oute1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) =
+ other Attr Tlv


   R=
oute2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) =
+ other Attr Tlv


 


  &n=
bsp;  Also in this format, when a peer join a peer set, how to create =
the route? Perhaps=1B$B!'=1B(B=



   R=
oute1: SRv6 SID NLRI1 (Local Node Desc + SID1) + Peer Node SID (pee=
r1) + other Attr Tlv


   R=
oute2: SRv6 SID NLRI1 (Local Node Desc + SID2) + Peer Node SID (S-f=
lag) + other Attr Tlv


   W=
hat=1B$B!G=1B(Bs
 the relationship about the two routes ?


   I=
f there exist a route3:


   R=
oute3: SRv6 SID NLRI1 (Local Node Desc + SID3) + Peer Node SID (S-f=
lag) + other Attr Tlv


   N=
ow the Peer node route1 belongs to route2=1B$B!G=1B(Bs
 Peer Set or route3=1B$B!G=1B(=
Bs Peer Set?=



 


   B=
ut it=1B$B!G=1B(Bs
 clear for old mpls epe draft:


   R=
oute1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) =
+ Peer Set Sid(set1)+other Attr Tlv


   R=
oute2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) =
+ Peer Set Sid(set1)+ other Attr Tlv


 


 


 


Best Regards


Haibo=



 
--_000_CY4PR11MB1541C5879E31284C683E1DB8C1620CY4PR11MB1541namp_--