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

["Aijun Wang" <[e-mail]>]

Hi, Ketan:

 

I think there is another reason that causes this semantic error-----that is there is many similarities for the definition of “Adj-SID Sub-TLV” for ISIS and OSPFv3 in the following draft:

https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-11#section-6.1

https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-15#section-2.2.1

 

but there is no any description in the relevant paragraph to  distinguish them in BGP-LS document.

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

 

Ketan explained that “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.” But when I compared another TLV definition “SRMS Preference TLV” in randomly, I found the definition in BGP-LS is different from that both in ISIS and OSPFv3.(include the “length” field and “reserved” field) I don’t know there are how many inconsistence among them and think this will induce other inconsistencies when the vendor implements the BGP-LS protocol.

 

Can we align these definitions as consistence as possible among them? Or add clear distinguish statements for the different IGP protocol?

The consumer can add some detections for such kind semantic errors but the better is not to produce them.

 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Ketan Talaulikar (ketant) [mailto:[e-mail]] 
发送时间: 2018年4月4日 15:54
收件人: Aijun Wang
抄送: Jeffrey Haas; [e-mail]; [e-mail]
主题: Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

 

< 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 <[e-mail]> 
Sent: 04 April 2018 07:50
To: 'stefano previdi' <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>
Cc: [e-mail]; Ketan Talaulikar (ketant) <[e-mail]>; Acee Lindem (acee) <[e-mail]>
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.

 



 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 

-----邮件原件-----
发件人: stefano previdi [mailto:[e-mail]] 
发送时间: 2018年4月3日 15:39
收件人: Peter Psenak
抄送: [e-mail]; 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 < <mailto:[e-mail]> [e-mail]> 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 < <mailto:[e-mail]> [e-mail]> on behalf of "Ketan Talaulikar 

>> (ketant)" < <mailto:[e-mail]> [e-mail]>

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

>> *To: *Aijun Wang < <mailto:[e-mail]> [e-mail]>

>> *Cc: *" <mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]> [e-mail]>

>> *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 < <mailto:[e-mail]> [e-mail]>

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

>> *To:* Ketan Talaulikar (ketant) < <mailto:[e-mail]> [e-mail]>

>> *Cc:*  <mailto:[e-mail]> [e-mail]

>> *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) 

>> < <mailto:[e-mail]%3cmailto:[e-mail]> [e-mail]<mailto:[e-mail]>> 写道：

>> 

>>    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> 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 < <mailto:[e-mail]%3cmailto:[e-mail]> [e-mail]<mailto:[e-mail]>> *On

>>    Behalf Of *Aijun Wang

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

>>    *To:*  <mailto:[e-mail]%3cmailto:[e-mail]> [e-mail]<mailto:[e-mail]>

>>    *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> 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> 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> 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

>>     <mailto:[e-mail]%3cmailto:[e-mail]> [e-mail]<mailto:[e-mail]>

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

>> 

>> 

>> 

>> _______________________________________________

>> Lsr mailing list

>>  <mailto:[e-mail]> [e-mail]

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

>> 

> 

> _______________________________________________

> Lsr mailing list

>  <mailto:[e-mail]> [e-mail]

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

 

_______________________________________________

Lsr mailing list

 <mailto:[e-mail]> [e-mail]

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