A strong +1 from me as well. This is a clear example where the functional content is the same, but differences exist in the encoding for reasons which are specific to each protocol.
Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Peter Psenak (ppsenak) > Sent: Tuesday, April 03, 2018 12:35 AM > To: Acee Lindem (acee) <a...@cisco.com>; Ketan Talaulikar (ketant) > <ket...@cisco.com>; Aijun Wang <wangai...@tsinghua.org.cn> > Cc: lsr@ietf.org > Subject: Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" > between OSPF and ISIS extension for Segment Routing > > 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> 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-ext > > ensions-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-ext > > ensions-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 > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
