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

[Peter Psenak <[e-mail]>]

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.)


>
>> 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.

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).

>
>>> 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
> .
>