Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]
"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 09 August 2019 06:28 UTC
Return-Path: <jie.dong@huawei.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 2B3EC120045 for <idr@ietfa.amsl.com>; 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 <idr@ietfa.amsl.com>; 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 <idr@ietf.org>; 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 <idr@ietf.org>; 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)" <jie.dong@huawei.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Susan Hares <shares@ndzh.com>, 'idr wg' <idr@ietf.org>
Thread-Topic: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]
Thread-Index: AdVOH5HoHfsN7/tjRt2OgDiNu7rv6QAOQhOgAAE9k2AAAFbBgAACJeZQAATKS+A=
Date: Fri, 09 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> <BYAPR11MB35583AF4ABFB0B63F78B30DAC1D60@BYAPR11MB3558.namprd11.prod.outlook.com> <76CD132C3ADEF848BD84D028D243C927CCFFEBF9@NKGEML515-MBS.china.huawei.com> <BYAPR11MB3558D367D21B1BE4F9F1F772C1D60@BYAPR11MB3558.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3558D367D21B1BE4F9F1F772C1D60@BYAPR11MB3558.namprd11.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/idr/St-3QgHg8cT5arMwq5ILGjqNXXw>
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 <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: Fri, 09 Aug 2019 06:28:45 -0000
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 <shares@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 the bis draft. Thanks, Ketan From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> Sent: 09 August 2019 08:54 To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; 'idr wg' <idr@ietf.org<mailto:idr@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 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, Jie From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, August 09, 2019 10:57 AM To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; 'idr wg' <idr@ietf.org<mailto:idr@ietf.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 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. Thanks, Ketan From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Dongjie (Jimmy) Sent: 09 August 2019 08:14 To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; 'idr wg' <idr@ietf.org<mailto:idr@ietf.org>> 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 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 [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 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<mailto: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 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
- [Idr] Adoption call for draft-ketant-idr-rfc7752b… Susan Hares
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Acee Lindem (acee)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Jeff Tantsura
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Ketan Talaulikar (ketant)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Dongjie (Jimmy)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Ketan Talaulikar (ketant)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Dongjie (Jimmy)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Ketan Talaulikar (ketant)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Dongjie (Jimmy)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Stefano Previdi (IETF)
- [Idr] 答复: Adoption call for draft-ketant-idr-rfc7… Aijun Wang
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Adrian Farrel
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Balaji Rajagopalan
- Re: [Idr] 答复: Adoption call for draft-ketant-idr-… Ketan Talaulikar (ketant)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Ketan Talaulikar (ketant)
- Re: [Idr] Adoption call for draft-ketant-idr-rfc7… Jeffrey Haas