Hi Peter, Please see my response inline
> -----Original Message----- > From: Peter Psenak [mailto:[email protected]] > Sent: Friday, June 13, 2014 8:31 PM > To: Xuxiaohu; [email protected] 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:[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:) > > 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)? "...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? > 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)? 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 > >>> [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
