Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

"Dongjie (Jimmy)" <> Fri, 09 August 2019 03:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED4481200D5 for <>; Thu, 8 Aug 2019 20:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1y1ujsZ4446a for <>; Thu, 8 Aug 2019 20:24:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 536B71200A3 for <>; Thu, 8 Aug 2019 20:24:14 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 99C8511DFB4F15554F20 for <>; Fri, 9 Aug 2019 04:24:12 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 9 Aug 2019 04:24:11 +0100
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Fri, 9 Aug 2019 11:24:05 +0800
From: "Dongjie (Jimmy)" <>
To: "Ketan Talaulikar (ketant)" <>, Susan Hares <>, 'idr wg' <>
Thread-Topic: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]
Thread-Index: AdVOH5HoHfsN7/tjRt2OgDiNu7rv6QAOQhOgAAE9k2AAAFbBgA==
Date: Fri, 09 Aug 2019 03:24:05 +0000
Message-ID: <>
References: <000c01d54e1f$db81b080$92851180$> <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927CCFFEBF9NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]
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, 09 Aug 2019 03:24:17 -0000

Hi Ketan,

Thanks for your prompt feedback.

In my understanding, RFC7752 defines a general mechanism to distribute link-state and TE information to the consumer, IGP is just one source of that information. Also please note that the text quoted from bgp-ls-epe draft references RFC7752.

That said, it may be helpful to add some text in rfc7752bis to indicate that the rules about node/link descriptors are applicable to the protocol-IDs defined in this document, the rules for other protocol-IDs will be defined in documents which introduce the protocol-ID.

Best regards,

From: Ketan Talaulikar (ketant) []
Sent: Friday, August 09, 2019 10:57 AM
To: Dongjie (Jimmy) <>; Susan Hares <>; 'idr wg' <>
Subject: RE: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

Hi Jie,

Thanks for your review and comments.

Let us note that RFC7752 was about pushing IGP link-state via BGP-LS and as such the link descriptors that it mentions are applicable in the scenario where the protocol is OSPF or IS-IS. The BGP EPE draft introduced the BGP protocol and specified the link descriptors for BGP peering links use case. As such, RFC7752 and BGP EPE are not in conflict or contradiction with each other.

This bis draft merely clarifies RFC7752 and is therefore scoped only for the IGP link-state propagation via BGP-LS.


From: Idr <<>> On Behalf Of Dongjie (Jimmy)
Sent: 09 August 2019 08:14
To: Susan Hares <<>>; 'idr wg' <<>>
Subject: Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]


In general I support the adoption of this document. It helps to clarify some confusions in RFC7752, and to solve some issues we realized during the progress of subsequent BGP-LS extensions.

And here are the comments I raised on the mic during IDR session in Montreal:

In section 4.2.2 of this -bis document, there are some changes to the encoding rules of link local/remote identifiers in the Link descriptors.

"    If interface and neighbor addresses, either IPv4 or IPv6, are
      present, then the IP address TLVs MUST be included and the Link
      Local/Remote Identifiers TLV MUST NOT be included in the Link
      Descriptor.  The Link Local/Remote Identifiers TLV MAY be included
      in the link attribute when available.

      If interface and neighbor addresses are not present and the link
      local/remote identifiers are present, then the Link Local/Remote
      Identifiers TLV MUST be included in the Link Descriptor."

While in draft-ietf-idr-bgpls-segment-routing-epe-19, section 4.2, it says:

" o  Link Descriptors MUST include the following TLV, as defined in

      *  Link Local/Remote Identifiers (TLV 258) contains the 4-octet
         Link Local Identifier followed by the 4-octet Link Remote
         Identifier.  The value 0 is used by default when the link
         remote identifier is unknown.

   o  Additional Link Descriptors TLVs, as defined in [RFC7752], MAY
      also be included to describe the addresses corresponding to the
      link between the BGP routers:

      *  IPv4 Interface Address (Sub-TLV 259) contains the address of
         the local interface through which the BGP session is

Thus it seems the above text in -7752bis is somewhat inconsistent with the bgp-ls-epe draft. Could this be considered in next revision of the bis draft, or the bgp-ls-epe draft? Thanks.

Best regards,

From: Idr [] On Behalf Of Susan Hares
Sent: Friday, August 09, 2019 3:31 AM
To: 'idr wg' <<>>
Subject: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

This begins a 2 week adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22/2019]

In your comments please indicate "support" or "no support".

The chair and AD feel that a revision to RFC7752 is needed
to specify additional error handling.  Please consider
if this draft is a good place to start for this revision.

Cheerily, Susan Hares