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

[Xuxiaohu <[e-mail]>]

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. 

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