Hi Aijun,

You say that certain parts of sections 3 (Procedures) are unnecessary and at 
the same time you ask for “some clarification” and for “error prone” TLV 
definitions.

I do not anymore follow your point or what is it that you want updated in 
draft-ietf-idr-bgp-ls-segment-routing-ext.

Thanks,
Ketan

From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: 10 April 2018 13:46
To: Ketan Talaulikar (ketant) <ket...@cisco.com>
Cc: 'Jeffrey Haas' <jh...@pfrc.org>; lsr@ietf.org; i...@ietf.org
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

Hi, Ketan:

I read through the section that you provided at 
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-3,
 and think 3/4 parts of them are unnecessary because the contents of 3.1,3.2 
and 3.3 has been mentioned at the corresponding TLV definition parts. Only 3.4 
part is necessary because it mentions the composite usage of two TLVs and can’t 
fit in any previous TLV definition.

My suggestion is that we add some clarification under the error-prone TLV 
definition respectively, to let the vendor refer them clearly when implementing 
the BGP-LS protocol.

ISIS/OSPF/OSPFv3/BGP-LS are different protocols in mainly the mechanism to 
transfer/digest the message, not the extensible TLVs definition, especially for 
the same purpose TLVs. There are some reasons that need to keep the definition 
compact/different, but beyond that, we should align them as same as possible to 
eliminate the error arose from inter-operation activities among different 
vendor or between device vendor and the SDN controller.


Best Regards.

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

发件人: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
发送时间: 2018年4月9日 16:45
收件人: Aijun Wang
抄送: 'Jeffrey Haas'; lsr@ietf.org<mailto:lsr@ietf.org>; 
i...@ietf.org<mailto:i...@ietf.org>
主题: Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

Hi Aijun,

As responded previously and also clarified by few others, the 3 IGP protocols 
(ISIS, OSPFv2 and OSPFv3) and BGP-LS are different protocols. Their encodings 
need not be identical. However, their semantics generally are so when it comes 
mapping them into BGP-LS.

At this stage, given the advance state of implementations and deployments for 
all these IGP and BGP-LS drafts involved, I don’t think we can undertake such 
“cosmetic” changes.

However, the draft-ietf-idr-bgp-ls-segment-routing-ext-04 is in WGLC and I can 
definitely take your feedback for any updates in the text or clarifications 
necessary in this document. Note that the procedures for the TLVs where 
mappings were non-trivial are described in the Procedures section - 
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-3
 . The TLVs you mention below are very trivial and the mapping from IGPs to 
BGP-LS is straightforward so the authors believe the explanation in Section 2 
where each TLV field is described is sufficient.

In the end, I am not sure if any of this helps/addresses implementation defects 
(where the reserved field itself was skipped from the BGP-LS TLV) that you have 
identified in your deployment on the producer side.

Thanks,
Ketan

From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Sent: 08 April 2018 07:02
To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>
Cc: 'Jeffrey Haas' <jh...@pfrc.org<mailto:jh...@pfrc.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

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:ket...@cisco.com]
发送时间: 2018年4月4日 15:54
收件人: Aijun Wang
抄送: Jeffrey Haas; lsr@ietf.org<mailto:lsr@ietf.org>; 
i...@ietf.org<mailto:i...@ietf.org>
主题: 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 <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Sent: 04 April 2018 07:50
To: 'stefano previdi' <stef...@previdi.net<mailto:stef...@previdi.net>>; Peter 
Psenak (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Ketan Talaulikar (ketant) 
<ket...@cisco.com<mailto:ket...@cisco.com>>; Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@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@01D3D0DD.F2CDF4D0]



Best Regards.

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



-----邮件原件-----
发件人: stefano previdi [mailto:stef...@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 
> <ppse...@cisco.com<mailto:ppse...@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-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of 
>> "Ketan Talaulikar

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

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

>> *To: *Aijun Wang 
>> <wangai...@tsinghua.org.cn<mailto:wangai...@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 
>> <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>

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

>> *To:* Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@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)

>> <ket...@cisco.com<mailto:ket...@cisco.com<mailto:ket...@cisco.com%3cmailto:ket...@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-boun...@ietf.org<mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org%3cmailto:lsr-boun...@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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to