> -----Original Message----- > From: Isis-wg [mailto:[email protected]] On Behalf Of Peter Psenak > Sent: Monday, June 16, 2014 3:17 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/16/14 04:58 , Xuxiaohu wrote: > > 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)? > > correct, max-metric means unreachable in ISIS.
> > > > "...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? > > Binding TLV in ISIS can be used to advertise "LSP path" as well as SRMS > mappings. I had wanted to say: "Don't you believe it's better for the Binding TLV in ISIS to be used ONLY to advertise a LSP as well?" In this way, the functionality of the Binding TLV keeps fully consistent in OSPF and ISIS. Best regards, Xiaohu > >> 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)? > > it's a matter of choice. Authors of ISIS draft choose the cleaner way IMHO. > regards, > Peter > > > > > 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 > >>> . > >>> > > > > . > > > > _______________________________________________ > 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
