Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR

[Xuxiaohu <[e-mail]>]

> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Peter Psenak
> Sent: Monday, June 16, 2014 3:17 PM
> To: Xuxiaohu; [e-mail] list; OSPF List
> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2
> extensions for SR
> 
> Xiaohu,
> 
> please see inline:
> 
> On 6/16/14 04:58 , Xuxiaohu wrote:
> > Hi Peter,
> >
> > Please see my response inline
> >
> >> -----Original Message-----
> >> From: Peter Psenak [mailto:[e-mail]]
> >> Sent: Friday, June 13, 2014 8:31 PM
> >> To: Xuxiaohu; [e-mail] list; OSPF List
> >> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2
> >> extensions for SR
> >>
> >> Hi Xiaohu,
> >>
> >> please see inline:
> >>
> >> On 6/13/14 12:09 , Xuxiaohu wrote:
> >>> Hi peter,
> >>>
> >>>> -----Original Message-----
> >>>> From: Isis-wg [mailto:[e-mail]] On Behalf Of Peter
> >>>> Psenak
> >>>> Sent: Friday, June 13, 2014 4:32 PM
> >>>> To: Xuxiaohu; [e-mail] list; OSPF List
> >>>> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and
> >>>> OSPFv2 extensions for SR
> >>>>
> >>>> Xiaohu,
> >>>>
> >>>> please see inline:
> >>>>
> >>>> On 6/13/14 09:51 , Xuxiaohu wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> There are some encoding inconsistencies between OSPFv2 extensions
> >>>>> and ISIS
> >>>> extensions for SR as follows:
> >>>>>
> >>>>> 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the
> >>>>> IP reachability
> >>>> advertisement. In OSPF-SR, the prefix-sid advertisement is
> >>>> piggybacked on OSPF Extended Prefix LSA which is used to advertise
> >>>> other attributes associated with the prefix, rather than the
> >>>> reachability. IMHO, the OSPF encoding is more flexible since the
> >>>> label distribution and the reachability advertisement are
> >>>> independent. As a result, the route summary on area boundaries at
> >>>> least can be enabled as before. Besides, the prefix-SID sub-TLV can
> >>>> be used to advertise a range of prefix/SID pairs (see item2). In
> >>>> fact, ISIS allows us to do the same way as OSPF with a much lower
> >>>> cost (see section 3 of
> >> http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of
> >> course, it seems that you co-authors prefer to the piggyback way.
> >>>>
> >>>> OSPF LSAs that are used to advertise the prefixex are not
> >>>> extensible, so we had to define a new LSA for the purpose of
> >>>> advertising a prefix related
> >> attributes.
> >>>> ISIS is different, as they can add sub-TLVs to existing TLVs.
> >>>
> >>> I see. For ISIS, you use the piggyback way (piggyback the label/sid
> >> advertisement on the reachability advertisement messages). For
> >> OSPFv2, you have no way to use the piggyback way anymore, so you defined
> a new LSA...
> >> That's why I said you prefer to the piggyback way. However, I don't
> >> think the piggyback way is much worthwhile from the perspective of
> >> flexibility and extensibility.
> >>>
> >>>>>
> >>>>> 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to
> >>>>> advertise an SID for a
> >>>> single prefix. And it relays on the SID/Label Binding TLV to
> >>>> advertise a range of prefix/SID pairs. In contrast, In OSPF-SR, the
> >>>> prefix-sid sub-TLV can be used to specify a range of addresses and
> >>>> their associated Prefix SIDs. By the way, in the 4.3.  SID/Label
> >>>> Binding sub-TLV. it has the following text: "Range Size: usage is
> >>>> the same as described in Section 4.2." Did you co-authors want to
> >>>> propose two ways (i.e., prefix-sid sub-TLV and SID-Label Binding
> >>>> sub-TLV) to achieve
> >> the same goal (i..e, advertise a range of prefix/SID pairs)?
> >>>>
> >>>> because in OSPF advertisement of the prefix SID is decoupled from
> >>>> the advertisement of prefix reachability, we can afford to
> >>>> advertise the range of SIDs in the prefix-SID sub-TLV as such.
> >>>
> >>> IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be
> >>> decoupled from the prefix reachability advertisement as well:)
> >>
> >> in OSPFv3 case, we have a way to advertise the prefix using the
> >> proposed encoding in draft-acee-ospfv3-lsa-extend, but do not
> >> advertise the reachability of the prefix - it's call NU-bit (rfc5340,
> >> A.4.1.1.)
> >
> > That's great. BTW, don't you believe the ISIS protocol has provided almost the
> same capability as the NU-bit (see the following text quoted from RFC5305)?
> 
> correct, max-metric means unreachable in ISIS.

> >
> > "...If a prefix is advertised
> >     with a metric larger then MAX_PATH_METRIC (0xFE000000, see
> paragraph
> >     3.0), this prefix MUST NOT be considered during the normal SPF
> >     computation.  This allows advertisement of a prefix for purposes
> >     other than building the normal IP routing table...".
> >
> >>>
> >>>> No, we do not define two ways to achieve the same thing. Binding
> >>>> TLV is used for a different purpose and the same usage is only
> >>>> applicable to the Range semantics, not to the whole Binding TLV.
> >>>
> >>> Does that mean the Binding sub-TLV in the OSPF-SR could not be used
> >>> to
> >> advertise a range of prefix/sid pairs while the binding sub-TLV in
> >> the ISIS-SR could?
> >>
> >> Binding TLV in OSPF is only used to advertise a "LSP path" local to
> >> the advertising router, it's not used for anything else. YOu can still advertise a
> single "LSP path"
> >> for range of prefixes.
> >
> > Don't you believe it's better for the Binding TLV in ISIS to be used to advertise a
> LSP as well?
> 
> Binding TLV in ISIS can be used to advertise "LSP path" as well as SRMS
> mappings.

I had wanted to say: "Don't you believe it's better for the Binding TLV in ISIS to be used ONLY to advertise a
LSP as well?" In this way, the functionality of the Binding TLV keeps fully consistent in OSPF and ISIS.

Best regards,
Xiaohu

> >> In ISIS, due to the need to decouple prefix reachability from SID
> >> advertisement, Binding TLV is used for SR Mapping Server (SRMS)
> >> adevrtisement on top of what it is used in OSPF (in OSPF SRMS
> >> advertisements are using the Prefix/SID sub-TLV).
> >
> > To decouple prefix reachability from SID advertisement, why not consider the
> approach of using the MAX_PATH_METRIC trick (see section 3 of
> http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00)?
> 
> it's a matter of choice. Authors of ISIS draft choose the cleaner way IMHO.

> regards,
> Peter
> 
> >
> > Best regards,
> > Xiaohu
> >
> >>>>> 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID
> >>>>> field since the
> >>>> MT-ID field is already contained in the parent TLV of the
> >>>> prefix-SID sub-TLV. In OSPF, the MT-ID field is contained in the
> >>>> Prefix SID Sub-TLV since the parent TLV of the prefix-sid sub-TLV
> >>>> doesn't contain that MT-ID field. IMHO, it's better to contain the
> >>>> MT-ID in the parent prefix-specific TLV of the prefix-SID sub-TLV.
> >>>> In other words, why not contain the MT-ID in the OSPF Extended
> >>>> Prefix TLV, instead of the prefix-sid sub-TLV (see section 3 of
> >> http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)?
> >>>>
> >>>> no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV.
> >>>> The reason is that attributes are MT specific, not the prefix itself - e.g.
> >>>> you may want to advertise different metrics for the same prefix in
> >>>> different topologies, not the same prefix twice.
> >>>
> >>> Make the prefix-sid as a sub-TLV of the Multi-Topology sub-TLV?
> >>
> >> no, we don't want to end up with sub-sub-TLVs right from the beginning.
> >>
> >> regards,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Xiaohu
> >>>
> >>>> regards,
> >>>> Peter
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Anyway, although it is unavoidable for us to define extensions to
> >>>>> both ISIS and
> >>>> OSPF for the same thing due to the fact that both protocols have
> >>>> been widely used, could we try our best to keep the encodings of
> >>>> ISIS and OSPF as consistent as possible for the same functionality?
> >>>> In this way, once someone has read the ISIS extension draft, he or
> >>>> she can easily think of what has been done in the OSPF extension
> >>>> draft accordingly,
> >> and vice verse.
> >>>>>
> >>>>> Best regards,
> >>>>> Xiaohu
> >>>>>
> >>>>> _______________________________________________
> >>>>> Isis-wg mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>>>> .
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Isis-wg mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>> .
> >>>
> >
> > .
> >
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg