Re: [Idr] [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Wed, 04 April 2018 07:54 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 D4C07126BF3; Wed, 4 Apr 2018 00:54:09 -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, DC_PNG_UNO_LARGO=0.001, 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, T_KAM_HTML_FONT_INVALID=0.01, 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 wCMUTWDS44yu; Wed, 4 Apr 2018 00:54:06 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C570D120047; Wed, 4 Apr 2018 00:54:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=97822; q=dns/txt; s=iport; t=1522828445; x=1524038045; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lSaPFoSuTVsAgupMyYiD+JPwAAke5s7METc0qN1wzXM=; b=LnGbgmpDJHa/D1PygVlDR+EM1A6tX2LLFmzM2R02aOh7IDK9yqtDh39y 2S9duY0gmwIG0u4GmFXmVOoQ20Khz2o6EzYXyN9Le55ogTqR1yPahdTbB AtR1L6QmAK5z1KBfIhSFC6k0cDEbGtrn2b1KZO0HFSvR2eKIHKNWS7eUj 4=;
X-Files: image001.png : 19745
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAQBkg8Ra/5hdJa0bAz8ZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgk11YW8oCoNViACNB4F0gQ+SVYF6CAECGAEMhF4CGoQ?= =?us-ascii?q?sITQYAQIBAQEBAQECaxwMhSIBAQEBAgEBAQMeAggBQAsFCwIBBgIRAwEBAQY?= =?us-ascii?q?BAQEYAQIEAwICAgUQAQ4BCxQJCAIEDgQBBgIGhHcID5ByDZs8ghyIR4IWCgW?= =?us-ascii?q?HYoFUP4EMgghOLoMRAQECAYEyBwEBNQkWgkqCVAKHCYRpC4RIhnYIAoUDAU2?= =?us-ascii?q?FLoEagg6BOBqDP4YggRCHJoFvhkECERMBgSQBHDiBUnAVOoJDgh0DFxGISIU?= =?us-ascii?q?+bwEBiyECDRcHgQGBFwEB?=
X-IronPort-AV: E=Sophos;i="5.48,405,1517875200"; d="png'150?scan'150,208,217,150";a="369484681"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 07:54:04 +0000
Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w347s4Mc003030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Apr 2018 07:54:04 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 4 Apr 2018 02:54:03 -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; Wed, 4 Apr 2018 02:54:03 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
CC: "lsr@ietf.org" <lsr@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>
Thread-Topic: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing
Thread-Index: AdPKX89aH7daBvUkQYK90A0ibbwqrwAABY/wAAMor+AADI+6AAAKaB1g//+8yYCAAUKmgIAAASyAgAE5PQD///jZsA==
Date: Wed, 4 Apr 2018 07:54:03 +0000
Message-ID: <bb5ff9928fb245739ae5480b884f1edd@XCH-ALN-008.cisco.com>
References: <008101d3ca60$073f81b0$15be8510$@org.cn> <c5a4d1de5e7943318821018c138b5562@XCH-ALN-008.cisco.com> <1B346347-9242-4EE4-BDA2-F024EF483B8A@tsinghua.org.cn> <aab65c5b06d346d2a5a4ef8cef5ad28b@XCH-ALN-008.cisco.com> <8C26288C-54C3-4C04-91A6-2B99562A1DE9@cisco.com> <5AC32E8B.6090202@cisco.com> <CF9450C5-028B-4B29-9F3A-137254AFF320@previdi.net> <009b01d3cbbb$6bfc3510$43f49f30$@org.cn>
In-Reply-To: <009b01d3cbbb$6bfc3510$43f49f30$@org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.68.229]
Content-Type: multipart/related; boundary="_004_bb5ff9928fb245739ae5480b884f1eddXCHALN008ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Ldm3bTvRWFzNr76mttC8X6jubcA>
Subject: Re: [Idr] [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing
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: Wed, 04 Apr 2018 07:54:10 -0000

< including IDR WG where BGP-LS work is being done >

Hi Aijun,

As discussed offline, this is a bug in this particular implementation where it is not following the spec properly.

This goes back to the discussion in the IDR WG about the semantic and syntactic validation for BGP-LS messages which Jeff had brought up. In this case, my understanding was that there was a semantic error in this TLV encoding? The consumer (application/BGP speaker) in this case should detect and ignore this update – which is what was being done as well in this case?

Thanks,
Ketan

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Sent: 04 April 2018 07:50
To: 'stefano previdi' <stefano@previdi.net>et>; Peter Psenak (ppsenak) <ppsenak@cisco.com>
Cc: lsr@ietf.org; Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Acee Lindem (acee) <acee@cisco.com>
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing


Hi, All:



We have found some inconsistencies for the implementation of BGP-LS protocol regarding this “Adj-SID SubTLV ”, please see the following screenshot.

I think we should do some works for the related drafts to clarify this ambiguous/easy to be ignored definition.



[cid:image001.png@01D3CC17.DE8CCD40]



Best Regards.

Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.



-----邮件原件-----
发件人: stefano previdi [mailto:stefano@previdi.net]
发送时间: 2018年4月3日 15:39
收件人: Peter Psenak
抄送: lsr@ietf.org<mailto:lsr@ietf.org>; Ketan Talaulikar (ketant); Acee Lindem (acee); Aijun Wang
主题: Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing



me too.



If we want to align the encoding, we should probably better align the protocol name directly...



s.





> On Apr 3, 2018, at 9:34 AM, Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> wrote:

>

> On 02/04/18 14:19 , Acee Lindem (acee) wrote:

>> Speaking as WG member:

>>

>> I couldn’t agree more with Ketan. No changes are required to these

>> documents.

>

> as a coauthor of the OSPF/OSPFv3 SR drafts, I fully agree.

>

> thanks,

> Peter

>

>>

>> Thanks,

>>

>> Acee

>>

>> *From: *Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> on behalf of "Ketan Talaulikar

>> (ketant)" <ketant@cisco.com<mailto:ketant@cisco.com>>

>> *Date: *Monday, April 2, 2018 at 7:36 AM

>> *To: *Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>

>> *Cc: *"lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>

>> *Subject: *Re: [Lsr] Inconsistence regarding the definition of

>> "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

>>

>> Hi Aijun,

>>

>> I understand what you are referring to now, but these are not

>> inconsistencies. ISIS, OSPF and BGP-LS are 3 different protocols.

>> Their encodings may not all be the same. ISIS uses 1 byte for

>> type/length and has LSP space constraints which you would notice in

>> the protocol encodings. OSPF doesn’t have the same challenge and you

>> would notice how its TLVs tend to be aligned. BGP-LS is somewhat

>> similar to OSPF from these size constraints perspective.

>>

>> I do not see the implementation challenges in encoding from the two

>> IGPs into BGP-LS. It does not make sense to change any of the

>> protocol encodings that you ask for currently since implementations

>> have been shipping with them for many years.

>>

>> IMHO it is not necessary to put such constraints for what you call

>> “consistency” on these 3 protocol encodings in the future. However,

>> we do try to be consistent in semantics as much as possible.

>>

>> Thanks,

>>

>> Ketan

>>

>> *From:*Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>

>> *Sent:* 02 April 2018 16:52

>> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>

>> *Cc:* lsr@ietf.org<mailto:lsr@ietf.org>

>> *Subject:* Re: [Lsr] Inconsistence regarding the definition of

>> "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

>>

>> Hi, Ketan:

>>

>> There is one two-bytes “Reserved” field in “Adjacency Segment

>> Identifier” TLV for OSPF extension, but this field doesn’t exist in

>> the corresponding TLV for ISIS extension. Every other fields are same.

>>

>> Corresponding definition in BGP-LS is similar with OSPF(not similar

>> with ISIS as I mentioned in previous mail). Then when the router

>> reports/redistributes the ISIS LSDB information to BGP protocol, the

>> router must add two bytes to the “length” field and add/stuff the

>> “reserved” field; but for OSPF LSDB, the router need only copy the

>> corresponding fields according.

>>

>> We have found the error arises from this inconsistency from the real

>> router and think it is better to align this definition in different

>> IGP protocol.

>>

>> Update to ISIS related extensions draft may be easier.

>>

>> Aijun Wang

>>

>> China Telecom

>>

>>

>> 在 2018年4月2日,18:26,Ketan Talaulikar (ketant)

>> <ketant@cisco.com<mailto:ketant@cisco.com<mailto:ketant@cisco.com%3cmailto:ketant@cisco.com>>> 写道:

>>

>>    Hi Aijun,

>>

>>    Can you clarify what you mean by “inconsistencies”?

>>

>>    Also, you are referring the old version of OSPFv3 SR draft before it

>>    was aligned with the OSPFv2 SR draft. Please check

>>

>> https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-ex

>> tensions-11#section-6.1

>>

>>    OSPF and ISIS are different protocols and there are some differences

>>    between them. I would not call them inconsistencies. BGP-LS spec

>>    refers to the individual IGP drafts for interpretation of flags. So

>>    please specifically point out what inconsistency you are referring to.

>>

>>    Thanks,

>>

>>    Ketan

>>

>>    *From:*Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org%3cmailto:lsr-bounces@ietf.org>>> *On

>>    Behalf Of *Aijun Wang

>>    *Sent:* 02 April 2018 14:23

>>    *To:* lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>

>>    *Subject:* [Lsr] Inconsistence regarding the definition of "Adj-SID

>>    Sub-TLV" between OSPF and ISIS extension for Segment Routing

>>

>>    Hi, All:

>>

>>    We found there were some inconsistences for the definition of

>>    “Adjacency Segment Identifier” between OSPF and ISIS extension for

>>    segment routing, please see the link below for comparison.

>>

>>

>> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extension

>> s-15#section-2.2.1

>>

>>

>> https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-ex

>> tensions-10#section-7.1

>>

>>    Here we want to know is there any reason for this inconsistence? We

>>    think this inconsistence can easily cause error for BGP-LS

>>    implementation for segment routing extension, as that defined in

>>    https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-2.2.1,

>>    which is similar with ISIS extension for SR, but different from OSPF

>>    extension for SR.

>>

>>    Do we need to make them consistent? It seems change the definition

>>    in OSPF extension may be less influence for the existing related drafts.

>>

>>    Best Regards.

>>

>>    Aijun Wang

>>

>>    Network R&D and Operation Support Department

>>

>>    China Telecom Corporation Limited Beijing Research

>>    Institute,Beijing, China.

>>

>>    _______________________________________________

>>    Lsr mailing list

>>    Lsr@ietf.org<mailto:Lsr@ietf.org<mailto:Lsr@ietf.org%3cmailto:Lsr@ietf.org>>

>>    https://www.ietf.org/mailman/listinfo/lsr

>>

>>

>>

>> _______________________________________________

>> Lsr mailing list

>> Lsr@ietf.org<mailto:Lsr@ietf.org>

>> https://www.ietf.org/mailman/listinfo/lsr

>>

>

> _______________________________________________

> Lsr mailing list

> Lsr@ietf.org<mailto:Lsr@ietf.org>

> https://www.ietf.org/mailman/listinfo/lsr



_______________________________________________

Lsr mailing list

Lsr@ietf.org<mailto:Lsr@ietf.org>

https://www.ietf.org/mailman/listinfo/lsr