Speaking as WG member: I couldn’t agree more with Ketan. No changes are required to these documents.
Thanks, Acee From: Lsr <lsr-boun...@ietf.org> on behalf of "Ketan Talaulikar (ketant)" <ket...@cisco.com> Date: Monday, April 2, 2018 at 7:36 AM To: Aijun Wang <wangai...@tsinghua.org.cn> Cc: "lsr@ietf.org" <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> Sent: 02 April 2018 16:52 To: Ketan Talaulikar (ketant) <ket...@cisco.com> Cc: 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>> 写道： 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-extensions-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>> On Behalf Of Aijun Wang Sent: 02 April 2018 14:23 To: lsr@ietf.org<mailto: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-extensions-15#section-2.2.1 https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-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> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
