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

[Xuxiaohu <[e-mail]>]

> -----Original Message-----
> From: Xuxiaohu
> Sent: Friday, June 13, 2014 3:52 PM
> To: [e-mail] list; OSPF List
> Subject: Encoding inconsistency between ISIS and OSPFv2 extensions for SR
> 
> 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

s/ piggybacked on OSPF/ carried in 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.

The piggyback way here just means the current way used by the ISIS-SR.

Best regards,
Xiaohu

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


> 3. In ISIS-SR, the range of SID/Label values is advertised by the SR Capability
> sub-TLV. Meanwhile, the data-plane capability is advertised by such sub-TLV as
> well. In OSPF-SR, the range of SID/Label values is advertised by the label/sid
> range sub-TLV. I wonder what the special purpose of the data-plane capability
> advertisement is in the ISIS-SR case.
> 
> 4. In ISIS-SR, the Prefix-SID Sub-TLV can be sub-TLV of the SID/Label Binding-TLV
> and its' the the prefix-sid sub-TLV which is used to associate prefix-sids with the
> range of prefixes advertised by the SID/Label Binding TLV. In OSPF-SR, the
> prefix-sid sub-TLV and the SID/label binding sub-TLV are now at the same level of
> the sub-TLV hierarchy(i.e., both of them are sub-TLVs of the OSPF Extended
> Prefix TLV ). As a result. it's the SID/Label sub-TLV, rather than the prefix-sid
> sub-TLV which is used to associate prefix-sids with the range of prefixes.


> 5. In ISIS-SR, "The SID/Label Sub-TLV (Type: TBD, suggested value 1) contains the
> SID/Label value as defined in Section 2.3.  It MAY be present in the SID/Label
> Binding TLV" . However, in OSPF-SR, "SID/Label sub-TLV as described in Section
> 2.1.  This sub-TLV MUST appear in the SID/Label Binding Sub-TLV". In other
> words, the sid/label sub-TLV is optional to the SID/Label binding sub-TLV in the
> ISIS-SR case while the sid/label sub-TLV is mandatory to the SID/label binding
> TLV in the OSPF-SR case.
> 
> 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)?
> 
> 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