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 CE402120234; Thu, 8 Aug 2019 11:14:17 -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=YUA1mppH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=d8LN7rgd 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 w0BhlMZchT3Z; Thu, 8 Aug 2019 11:14:15 -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 2C213120230; Thu, 8 Aug 2019 11:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37021; q=dns/txt; s=iport; t=1565288054; x=1566497654; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=alLbCQAcZG8oky2xDYPkYIkFGv6QuNRX7CVQi/qyNJc=; b=YUA1mppHbVSM7+jEf8Q67Xg3jsQmIFt2KnrlStKeGNorS29PWf10hgBc zDxTI52liXZh7KjOYiN6KsnFJJjvKWqID949r748KUAKQ7uwyPbOYuMFj +wyCyEbYDi3gzfBD+kj46ejYWiHEXwltXkrmRlwcinI56K9QMEHsryu+J M=; IronPort-PHdr: =?us-ascii?q?9a23=3AwU2n5RN9Mxig2gHfAFcl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj4IeLjaTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAACVZUxd/4oNJK1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVQIBAQEBAQsBgRUvJCwDbVUgBAsqhB6DRwOLDoJbl2C?= =?us-ascii?q?BLoEkA1QJAQEBDAEBJQgCAQGEPwKCViM2Bw4BBAEBBAEBBAEKbYUnDIVKAQE?= =?us-ascii?q?BAQMSDwELEwEBMAcBDwIBCBEEAQEQEQEIAwIyHQgBAQQBDQUIGoMBgR1NAx0?= =?us-ascii?q?BAgyQD5BhAoE4iGBsAYE2gnoBAQWFFhiCFAMGgTQBi2MXgUA/gREBRYJMPoJ?= =?us-ascii?q?hAQECAYFgK4JbNYImlBeFPINBjUNnCQKCHYZfjWWYNo1Qh12QHAIEAgQFAg4?= =?us-ascii?q?BAQWBVgExgVhwFYMngkIMF4NOhRSDGYImcgGBKItqAQE?= X-IronPort-AV: E=Sophos;i="5.64,362,1559520000"; d="scan'208,217";a="393357015" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Aug 2019 18:14:12 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x78IECIh021871 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Aug 2019 18:14:12 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Aug 2019 13:14:12 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Aug 2019 13:14:11 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 8 Aug 2019 13:14:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XWuEpAkqxFwW1kNINPXXXUYZfWRowBOF8kneB/anf4PTQIaQTsheqz8GswMZEyiwMD8R1QWm7ABAm3Ot0WrbFMsHD3zdpBZFT/p3ClN2XeWMUZypkplUjo8ogQXx+yqJB2SsIVJ3VikOXWf2udzLO6z5V1rciGiAfuzQ7ZVHqW3ymLfcqhzUhNtw2c+/YK8em3rM8pfSfp+C+rSTChrNr4LQTnFiMlpMRRIZ7MOvKF88zZUhEEFz+Yn0uNnsM1KZibvDLGO/UBKu3YXkuXCE+TWM6nmlZet2ZfpVucjJAM5z7mGt9Txb6O1iLGwz92hRisCJTkM5+2Orre/8+5FoZQ== 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=fuDq5+VG1bYEKkKX+xvbv+IL19/KaMBsTZKYdQOMdkM=; b=WpeyAIl/tMvLAdz5uu6vNfNHEpBskZDzUbqm2OaFHZVzwisGeNDZVv0Al+70ZZ4mBf7w7CtUP+HV8eVujvmhWOoqhFuae6Gmv3XN+wHv1Uq51RAHZcwswmTUYXS8LJs9T3sNqnvParcnE5W4kJOXzfK7SWUYlfLvmzk+zr++ZTM/P9b6m8Up5RzK6oYGazEUYgea3RjUBCKyer6RHcRzA2oOdEAyMrqE2rcyGpt35dVbRt4Hk7W50/JKIGzil20Mt+1GHXt2+9UxU4LpMSK1g0S6+itX9Bfr1CghKimXfgf6ftV6HhgcMnXF9nX+2xrbls69JBOcJI40NghtpoG9ww== 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=fuDq5+VG1bYEKkKX+xvbv+IL19/KaMBsTZKYdQOMdkM=; b=d8LN7rgd/NhQv/YyT4vmhhiodJrFuIWtFhXkgQ/xBSy1eDegBkOLKZK90lBts1ek1JKCsCQJ7ENjZKx/S+IqBEL22E0EsH/Kd76Gu8xTEs8g/CGsDAlgzAj/MR0VKQ/UNogmaK/iNhYTbfxXqzL7zOGWv0FzKuHBBhYsqqhEMFs= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB3048.namprd11.prod.outlook.com (20.177.225.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Thu, 8 Aug 2019 18:14:09 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::3d73:9b60:6c26:2d0c]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::3d73:9b60:6c26:2d0c%6]) with mapi id 15.20.2136.018; Thu, 8 Aug 2019 18:14:09 +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: AdVMOJt7jNPQrPmHQpm89zff5sqK1gB15IJg Date: Thu, 8 Aug 2019 18:14:09 +0000 Message-ID: References: <1E61161D6E31D849BEA887261DB609348C8DDD73@nkgeml514-mbs.china.huawei.com> In-Reply-To: <1E61161D6E31D849BEA887261DB609348C8DDD73@nkgeml514-mbs.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: [2001:420:c0e0:1005::2b8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7a997820-c3cf-44c2-f22e-08d71c2c358d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3048; x-ms-traffictypediagnostic: BYAPR11MB3048: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(39860400002)(136003)(376002)(346002)(199004)(189003)(52536014)(966005)(7696005)(11346002)(53546011)(9326002)(478600001)(6506007)(9686003)(4326008)(6306002)(236005)(102836004)(8676002)(99286004)(76176011)(8936002)(33656002)(7736002)(55016002)(14454004)(81156014)(54896002)(6436002)(25786009)(81166006)(186003)(561944003)(6116002)(53936002)(790700001)(256004)(86362001)(46003)(476003)(5660300002)(446003)(6246003)(606006)(66446008)(2501003)(66946007)(110136005)(486006)(2906002)(71200400001)(71190400001)(64756008)(229853002)(76116006)(4743002)(316002)(74316002)(66556008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3048; H:BYAPR11MB3558.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-message-info: r+XMIs6VVhu73CYAYtsYjkcPpfKWHjg65W+Punjej5Imxaic+wtI4UwLHZ2dpRBX70qrgy4X4s9/JiLs3HX8PVgNDlQS/sGuoMjoJvkQSuTt6O7Xc+E1tMBvcFXVfbp+IZlBod3nv1s5LTij5Z+B61hjyeghPJMfCGt/YFpxcgdpbQL3sVqk8NJCaM/cYcvZUumuytB1Vnf8WfbUbTt9rajH/lod2jyYqPAYKTq4HYIzHtPzSf/UCa5gdtup/zEQWlniN+0QO4NfNOH07LzJf3XSfPFGGEbfzS2fvlV/2KMS2T8W3CyBm+YneWLH5LwKTusKnoFt1zCO2sA0bphX6VS4VcN8NE/hOzz9Kpde2Y6RHi1Wrt8MVmp6eOTxFKdx1FqHZrqIAaGx/Ul1/PUBGqNBrM/euGVGw9OukVIAvJk= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB355865E74489A61656883C5CC1D70BYAPR11MB3558namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7a997820-c3cf-44c2-f22e-08d71c2c358d X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 18:14:09.6609 (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: ketant@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3048 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: alln-core-5.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: Thu, 08 Aug 2019 18:14:18 -0000 --_000_BYAPR11MB355865E74489A61656883C5CC1D70BYAPR11MB3558namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable 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_BYAPR11MB355865E74489A61656883C5CC1D70BYAPR11MB3558namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

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 S= ID is associated with an underlying interface to the connected peer. In alm= ost 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 case we created another BGP-L= S 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 may not be same depending on whether the session is single-h= op (i.e. using interface addresses for peering) or multi-hop (e.g. using lo= opback addresses for peering). Note in https://tools.ietf.org/html/draft-ietf-idr-= bgpls-segment-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-hop session.

    3.  

    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@huaw= ei.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 E=
nd.X SID of the link state routing adjacency or the BGP EPE
    

         &n=
bsp;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 No=
de SID TLV
    

       The BGP Peer N=
ode 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.  Th=
e SRv6 BGP Peer Node SID TLV is an
    

       optional =
TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI<=
/b>
    

       correspon=
ding to BGP protocol.  This TLV MU=
ST 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 fo=
llowed by the SRv6 SID NLRI
    

     
    

    6.  SRv6 SID NLRI=

    

     

       A new "Li=
nk-State NLRI Type" is defined for SRv6 SID information as<=
/span>
    

       following:
    

     

       o  Link-S=
tate NLRI Type: SRv6 SID NLRI (value TBD see IANA
    

        &nb=
sp; Considerations Section 8.1).
    

     
    

         0&=
nbsp;           &nbs=
p;      1       =
;            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
    

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

        |  =
Protocol-ID  |
    

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

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

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

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

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

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

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

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

     

     

        &nb=
sp;            =
     Figure 11: SRv6 SID NLRI Format<=
/pre>

      &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_BYAPR11MB355865E74489A61656883C5CC1D70BYAPR11MB3558namp_--