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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Peter Psenak (ppsenak)
> Sent: Tuesday, April 03, 2018 12:35 AM
> To: Acee Lindem (acee) <[e-mail]>; Ketan Talaulikar (ketant)
> <[e-mail]>; Aijun Wang <[e-mail]>
> Cc: [e-mail]
> 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 <[e-mail]> on behalf of "Ketan Talaulikar
> > (ketant)" <[e-mail]>
> > *Date: *Monday, April 2, 2018 at 7:36 AM
> > *To: *Aijun Wang <[e-mail]>
> > *Cc: *"[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 <[e-mail]>
> > *Sent:* 02 April 2018 16:52
> > *To:* Ketan Talaulikar (ketant) <[e-mail]>
> > *Cc:* [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)
> > <[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-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 <[e-mail]<mailto:[e-mail]>> *On
> >     Behalf Of *Aijun Wang
> >     *Sent:* 02 April 2018 14:23
> >     *To:* [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-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
> >     [e-mail]<mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/lsr
> >
> >
> >
> > _______________________________________________
> > Lsr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr
> >
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr