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 2B3EC120045 for ; Thu, 8 Aug 2019 23:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i2LaGES6018 for ; Thu, 8 Aug 2019 23:28:42 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E4312000E for ; Thu, 8 Aug 2019 23:28:41 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 319E95EAB9AEA9212393 for ; Fri, 9 Aug 2019 07:28:39 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 9 Aug 2019 07:28:38 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.242]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Fri, 9 Aug 2019 14:23:18 +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/tjRt2OgDiNu7rv6QAOQhOgAAE9k2AAAFbBgAACJeZQAATKS+A= Date: Fri, 9 Aug 2019 06:23:18 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927CCFFECA4@NKGEML515-MBS.china.huawei.com> References: <000c01d54e1f$db81b080$92851180$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927CCFFEB7A@NKGEML515-MBS.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927CCFFEBF9@NKGEML515-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927CCFFECA4NKGEML515MBSchi_" 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-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, 09 Aug 2019 06:28:45 -0000 --_000_76CD132C3ADEF848BD84D028D243C927CCFFECA4NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, Thanks for considering my suggestion. Best regards, Jie From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, August 09, 2019 12:05 PM 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, Agree and I will put some text to this effect in the next update of the bis= draft. Thanks, Ketan From: Dongjie (Jimmy) > Sent: 09 August 2019 08:54 To: Ketan Talaulikar (ketant) >; = Susan Hares >; 'idr wg' > Subject: RE: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/= 8 to 8/22] 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 i= nformation. Also please note that the text quoted from bgp-ls-epe draft ref= erences RFC7752. That said, it may be helpful to add some text in rfc7752bis to indicate tha= t 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, Jie From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, August 09, 2019 10:57 AM To: Dongjie (Jimmy) >; Susa= n 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 p= rotocol 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 th= e IGP link-state propagation via BGP-LS. Thanks, Ketan 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] Hi, In general I support the adoption of this document. It helps to clarify som= e confusions in RFC7752, and to solve some issues we realized during the pr= ogress of subsequent BGP-LS extensions. And here are the comments I raised on the mic during IDR session in Montrea= l: In section 4.2.2 of this -bis document, there are some changes to the encod= ing 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 [RFC7752]: * 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 established." 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 draf= t, or the bgp-ls-epe draft? Thanks. Best regards, Jie From: Idr [mailto:idr-bounces@ietf.org] 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 --_000_76CD132C3ADEF848BD84D028D243C927CCFFECA4NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan,

 

Thanks for considering my suggestion.

 

Best regards,

Jie

 

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Friday, August 09, 2019 12:05 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com>; Susan Hares <sha= res@ndzh.com>; 'idr wg' <idr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.= txt [8/8 to 8/22]

 

Hi Jie,

 

Agree and I will put some text to this effect in the next update of t= he bis draft.

 

Thanks,

Ketan

 

From: Dongjie (Jimmy) <jie.= dong@huawei.com>
Sent: 09 August 2019 08:54
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; 'idr wg' <i= dr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.= txt [8/8 to 8/22]

 

Hi Ketan,

 

Thanks for your prompt feedback.

 

In my understanding, RFC7752 defines a general mechanism to distr= ibute 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.<= /span>

 

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

 

Best regards,

Jie

 

From: Ketan Talaulikar (ketant) [= mailto:ketant@cisco.com]
Sent: Friday, August 09, 2019 10:57 AM
To: Dongjie (Jimmy) <jie.d= ong@huawei.com>; Susan Hares <= shares@ndzh.com>; 'idr wg' <idr@i= etf.org>
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 sce= nario where the protocol is OSPF or IS-IS. The BGP EPE draft introduced the BGP protocol and specified the link descr= iptors 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.

 

Thanks,

Ketan

 

From: Idr <idr-bounces@iet= f.org> On Behalf Of Dongjie (Jimmy)
Sent: 09 August 2019 08:14
To: Susan Hares <shares@ndzh.c= om>; 'idr wg' <idr@ietf.org&g= t;
Subject: Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.= txt [8/8 to 8/22]

 

Hi,

 

In general I support the adoption of this document. It helps to c= larify some confusions in RFC7752, and to solve some issues we realized dur= ing 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 descriptor= s.

 

“    If interface and neighbor addresses, ei= ther 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/R= emote Identifiers TLV MAY be included

      in the link attribute when availab= le.

 

      If interface and neighbor addresse= s are not present and the link

      local/remote identifiers are prese= nt, then the Link Local/Remote

      Identifiers TLV MUST be included i= n 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

      [RFC7752]:

 

      *  Link Local/Remote Identifi= ers (TLV 258) contains the 4-octet

         Link Local Ident= ifier followed by the 4-octet Link Remote

         Identifier. = ; The value 0 is used by default when the link

         remote identifie= r is unknown.

 

   o  Additional Link Descriptors TLVs, as defined= in [RFC7752], MAY

      also be included to describe the a= ddresses corresponding to the

      link between the BGP routers:=

 

      *  IPv4 Interface Address (Su= b-TLV 259) contains the address of

         the local interf= ace through which the BGP session is

         established.R= 21;

 

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 th= e bis draft, or the bgp-ls-epe draft? Thanks.

 

Best regards,

Jie

 

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

 

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

 

In your comments please indicat= e “support” or “no support”.  

 

The chair and AD feel that a re= vision to RFC7752 is needed

to specify additional error han= dling.  Please consider

if this draft is a good place t= o start for this revision.

 

Cheerily, Susan Hares

--_000_76CD132C3ADEF848BD84D028D243C927CCFFECA4NKGEML515MBSchi_--