IETF Logo Mail Archive

Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 16 March 2018 02:50 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 7506E127010 for <idr@ietfa.amsl.com>; Thu, 15 Mar 2018 19:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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
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 gcHYuc0AfKA5 for <idr@ietfa.amsl.com>; Thu, 15 Mar 2018 19:50:45 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF7F126DFB for <idr@ietf.org>; Thu, 15 Mar 2018 19:50:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2580; q=dns/txt; s=iport; t=1521168645; x=1522378245; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6j9OokVfhoSs0xh/CxjnJnXrWrCXyIFF9IWOUz5y1fo=; b=ThHYR/MxmYMbC+iyeZ5FFK209PaZnEokl9Khn0pUQLbiA+XQRnLiOE7p xGE2XEd9zhQAC5TXn6n6epCavHJxAou5ZANK/9XMmid1vY99LyqGje1Nz r1ZcReaHvwgtRbpkx7oKYNeBurO65vR+XmoetwOhyS4UOgLLNikQDCt9D Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AIAQAtMKta/5JdJa1eGQEBAQEBAQEBAQEBAQcBAQEBAYNQZHEoCo1gjXeCA3sbk3uCEgoYC4RtAoM0ITQYAQIBAQEBAQECayiFJQEBAQMBAQE4NAsFBwQCAQgOAwQBAQEeECcLHQgCBAENBQiFCAgPsgqIZoIFBYUughSBVIFUgm0zgUGBXQEBAgGHTAORI4Z9CQKGBIkZgVeDfIJwhHGJK4ZYAhETAYEpAR44gVJwFTqCQ4Jljgh0AQGOeYEYAQEB
X-IronPort-AV: E=Sophos;i="5.48,313,1517875200"; d="scan'208";a="368219959"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2018 02:50:44 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w2G2oi0x016093 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Mar 2018 02:50:44 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Mar 2018 21:50:43 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Thu, 15 Mar 2018 21:50:43 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Susan Hares <shares@ndzh.com>
CC: 'idr wg' <idr@ietf.org>
Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)
Thread-Index: AQHTvLJwsPGlDZ7q5kWwiGwlvN25RqPSJ2Pw
Date: Fri, 16 Mar 2018 02:50:43 +0000
Message-ID: <8acfb154b77f4ba883b3ec3445986b04@XCH-ALN-008.cisco.com>
References: <011201d3b633$0b5fee60$221fcb20$@ndzh.com> <20180315230734.GB6209@pfrc.org>
In-Reply-To: <20180315230734.GB6209@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.62.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hMbokQb6V1zn98_xTJU-yIxaKos>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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, 16 Mar 2018 02:50:48 -0000

Hi Jeff,

Thanks for your review and please check inline below.

-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
Sent: 16 March 2018 04:38
To: Susan Hares <shares@ndzh.com>
Cc: 'idr wg' <idr@ietf.org>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

On Wed, Mar 07, 2018 at 11:40:46AM -0500, Susan Hares wrote:
> This begins a 2 week WG LC for
> draft-ietf-idr-bgp-ls-segment-routing-ext-04.txt from March 7th to March 21.
> During your discussion in the WG LC, please indicate the following things: 
> 
>  
> 
> 1)      Do you think BGP should carry these link state information regarding
> segment routing,

I do.

> 2)      Are there any technical issues with this draft? 

Minor comments as part of a re-read while waiting on my plane:
RESERVED is not called out in its behavior.  Some place in the document should mention the usual "MUST be set to zero on send, SHOULD be ignored on receipt".  Otherwise, it's gibberish in, who knows what out when someone tries to use this field in the future.
[KT] Thanks for catching this miss. I will fix this in the next revision.

There are a number of TLV value fields that may be of variable lengths.  In many cases, those lengths are inherited from the underlying IGP documents.
What is not documented is the behavior when the TLV is well formed but has unexpected length values.  Two simple examples:
- Prefix Attribute Flag TLV; varies by IGP
- Preference TLV; must be 1.

Do we treat this as malformed?  Do we ignore the sub-tlv?
[KT] I believe this is clarified in the base BGP-LS spec (https://tools.ietf.org/html/rfc7752#section-6.2.2). Do we need to clarify/call out anything extra in this specific document? IMHO it would be rather complex for BGP implementation (e.g. transit routers which do not understand or consume all these TLVs) to do semantic checking on these large set of TLVs being introduced in BGP-LS. This is something that could be left to the actual consumer of the information (e.g. controllers/applications). When a specific sub-TLV is using a wrong length (or have some other semantic error), it could be ignored by the consumer. This would apply to BGP-LS in general and not a specific document/extension.


> 
> 3)      Is this draft is ready for publication? 

Largely.

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email