Hi peter, > -----Original Message----- > From: Isis-wg [mailto:[email protected]] On Behalf Of Peter Psenak > Sent: Friday, June 13, 2014 4:32 PM > To: Xuxiaohu; [email protected] 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:) > 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? > > 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? 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/isis-wg > > . > > > > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
