Re: [Idr] [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 08 August 2019 18:14 UTC

Return-Path: <ketant@cisco.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 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: 9a23:wU2n5RN9Mxig2gHfAFcl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBj4IeLjaTASF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAACVZUxd/4oNJK1mGQEBAQEBAQEBAQEBAQcBAQEBAQGBVQIBAQEBAQsBgRUvJCwDbVUgBAsqhB6DRwOLDoJbl2CBLoEkA1QJAQEBDAEBJQgCAQGEPwKCViM2Bw4BBAEBBAEBBAEKbYUnDIVKAQEBAQMSDwELEwEBMAcBDwIBCBEEAQEQEQEIAwIyHQgBAQQBDQUIGoMBgR1NAx0BAgyQD5BhAoE4iGBsAYE2gnoBAQWFFhiCFAMGgTQBi2MXgUA/gREBRYJMPoJhAQECAYFgK4JbNYImlBeFPINBjUNnCQKCHYZfjWWYNo1Qh12QHAIEAgQFAg4BAQWBVgExgVhwFYMngkIMF4NOhRSDGYImcgGBKItqAQE
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)" <ketant@cisco.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>, "draft-ietf-idr-bgpls-srv6-ext@ietf.org" <draft-ietf-idr-bgpls-srv6-ext@ietf.org>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext
Thread-Index: AdVMOJt7jNPQrPmHQpm89zff5sqK1gB15IJg
Date: Thu, 08 Aug 2019 18:14:09 +0000
Message-ID: <BYAPR11MB355865E74489A61656883C5CC1D70@BYAPR11MB3558.namprd11.prod.outlook.com>
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: <BYAPR11MB30482330C1E858D790F3E757C1D70@BYAPR11MB3048.namprd11.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/idr/vgebFrpP6bO7kTzo3hzAkoNUp5o>
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 <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: Thu, 08 Aug 2019 18:14:18 -0000

Hi Haibo,

Thanks for your review and your comments. The draft proposal for how EPE SIDs are signalled for SRv6 do differ from how they are done for SR/MPLS. This change is based on our implementation and deployment experience - there was 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 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’s 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-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 may not be same depending on whether the session is single-hop (i.e. using interface addresses for peering) or multi-hop (e.g. using loopback 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.

This new/additional Link NLRI for the signalling of PeerNode and PeerSet SIDs 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 remote peer information. So it will become:
NLRI : SRv6 SID NLRI1 (local node desc + SID1)  and with it in BGP-LS Attribute : Peer Node SID TLV (peer1)
NLRI : SRv6 SID NLRI2 (local node desc + SID2)  and with it in BGP-LS Attribute : Peer Node SID TLV (peer2)

Now, for the PeerSet SID, it is actually the same SID that is associated with 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 Attribute : Peer Node SID TLV (peer 1 + Sflag=set), Peer Node SID TLV (peer 2 + Sflag=set)

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 corresponding to the PeerAdj SID without requiring additional Link NLRIs (with different descriptors) for the PeerNode and PeerSet SIDs.

I hope this clarifies and explains the reason for departure from EPE 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,
     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 more 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) + other Attr Tlv
   Route2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) + other Attr Tlv

     Also in this format, when a peer join a peer set, how to create the route? Perhaps:
   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’s 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’s Peer Set or route3’s Peer Set?

   But it’s clear for old mpls epe draft:
   Route1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) + Peer Set Sid(set1)+other Attr Tlv
   Route2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) + Peer Set Sid(set1)+ other Attr Tlv



Best Regards
Haibo