Hi Peter, > -----邮件原件----- > 发件人: Peter Psenak [mailto:[email protected]] > 发送时间: 2014年1月28日 16:15 > 收件人: Xuxiaohu > 抄送: [email protected]; [email protected]; [email protected] > 主题: Re: [OSPF] fwd: New Version Notification for > draft-xu-ospf-global-label-sid-adv-00.txt > > Xiaohu, > > > please see inline (##PP): > > > On 1/28/14 04:46 , Xuxiaohu wrote: > > Hi Peter, > > > >> -----邮件原件----- > >> 发件人: Peter Psenak [mailto:[email protected]] > >> 发送时间: 2014年1月27日 18:08 > >> 收件人: Xuxiaohu > >> 抄送: [email protected]; [email protected] > >> 主题: Re: [OSPF] fwd: New Version Notification for > >> draft-xu-ospf-global-label-sid-adv-00.txt > >> > >> Xiaohu, > >> > >> On 1/27/14 10:49 , Xuxiaohu wrote: > >>> Hi Peter, > >>> > >>>> -----邮件原件----- > >>>> 发件人: Peter Psenak [mailto:[email protected]] > >>>> 发送时间: 2014年1月27日 16:41 > >>>> 收件人: Xuxiaohu > >>>> 抄送: [email protected]; [email protected] > >>>> 主题: Re: [OSPF] fwd: New Version Notification for > >>>> draft-xu-ospf-global-label-sid-adv-00.txt > >>>> > >>>> Xiaohu, > >>>> > >>>> > >>>> 1. draft-psenak-ospf-segment-routing-extensions has already defined > >>>> the mapping server functionality - please read the section 4.2 and > >>>> 6.1 > >>> > >>> According to the description about mapping servers (see below) which > >>> is in -01 > >> version of the use case draft but is removed in -02 version of that > >> draft, it seems that the mapping server is deemed to advertise the > >> mappings on behalf of non-SR-capable routers. In contrast, my draft > >> proposes to allow the mapping server to allocate and advertise mappings on > behalf of SR-capable routers. > >> Those two distinct design goals cause different implications on the > >> implementation and usage. > >> > >> that is not true. MS as we support it with existing drafts can be > >> used to advertise SID/label for SR capable routers. > > > > This above argument may be true for the OSPF extension for SR draft since > > the > Prefix-SID are attached to OSPFv2 Extended Prefix Opaque LSA which is not > used for building the normal IP routing table. But I doubt whether the above > argument is still true for the ISIS extension for SR draft since the > Prefix-SID > Sub-TLV is attached to the Extended IP Reachability TLV which is exactly used > for > building the normal IP routing table, according to the existing description > of that > draft. > > ##PP > in ISIS, you can use SID/Label Binding TLV to advertise SID/label for prefix > for > which you do not want to advertise IP reachability.
In the SID/Label Binding TLV, the MT-ID information is missed. I wonder why not directly reuse the extended IP reachability TLVs to carry the Label/SID bindings by setting the Metric field to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). According to the following specification as defined in [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...". In addition, as stated in the section 2.2 of Prefix-SID Sub-TLV, "The 'Prefix SID' is an index to determine the actual SID/label value inside the set of all advertised SID/label ranges of a given router. " In section 2.1 of SID/Label Sub-TLV, it said "... The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this document and contains a SID or a MPLS Label". In the section 2.4 of SID/Label Binding TLV, it said "...X-Flag: Index flag. Set if the value of the SID/Label Sub-TLV carries an index. Unset if the value of the SID/Label Sub-TLV carries a local SID/Label. " Does the above description seem conflicting? Furthermore, in case the SID/Label Sub-TLV carries a "local" SID/Label, does that mean this Sub-TLV is not suitable for a mapping server to advertise the global ID (of whatever format) for a given prefix? Best regards, Xiaohu > regards, > Peter > > > > > > Best regard, > > Xiaohu > > > >>> "The mappings advertised by an SR mapping server result from local > >>> policy information configured by the operator. IF PE3 had been SR > >>> capable, the operator would have configured PE3 with node segment > >>> 103. Instead, as PE3 is not SR capable, the operator configures that > >>> policy at the SRMS and it is the latter which advertises the > >> mapping."---quoted from -01 version of the use case draft. > >>> > >>>> 2. TLVs that you defined in section 3 and 4 are very close to those > >>>> defined in draft-psenak-ospf-segment-routing-extensions and have > >>>> the exact same functionality as the ones defined in > >>>> draft-psenak-ospf-segment-routing-extensions > >>> > >>> If I understand your draft correctly, the prefix SID sub-TLV defined > >>> in your draft is intended to advertise index, rather than SID or > >>> global label. In contrast, the Label Binding > >> Sub-TLV and SID Binding Sub-TLV defined in my draft are intended to > >> advertise global labels and SIDs respectively. Besides, the Label > >> Binding Sub-TLV and SID Binding sub-TLV are just intended for label > >> or SID distribution without any correlation with the algorithm and > >> MT-ID, which is different from the prefix SID sub-TLV, IMHO. > >> > >> you can advertise an absolute value of the label/SID with existing > >> TLVs > >> - simply advertise the label/sid range starting from 0. MT-ID and > >> algorithm fields of 0 means default topology and SPT tree, which is what > >> you > want anyway. > > > >>> > >>>> 3. The only new sub-TLV you defined is Label Request Sub-TLV. > >>>> > >>>> First, given that we already have OSPF SR draft, you should have > >>>> defined this as a sub-TLV of the OSPF Extended Prefix TLV that is > >>>> defined in draft-psenak-ospf-segment-routing-extensions. > >>> > >>>> Second, you proposed to use Opaque LSA that is flooded either area > >>>> or domain wide as a request mechanism between the router and > >>>> mapping server. This means that all routers in an area/domain would > >>>> have to store and maintain such 'request' LSAs, even though they > >>>> would never use them locally. I seriously question if flooding of > >>>> the LSA is the right > >> mechanism to achieve what you want. > >>> > >>> Agree that it may not be attractive in the OSPF case. However, this > >>> choice may > >> be attractive in the IS-IS case since the label/SID request > >> information can be carried in the IP reachability advertisement. > >> Anyway, as said in the draft, the advertisement of label/SID request is > >> just > one option. > >> > >> I do not see how ISIS is different - LSP is still flooded with area scope. > >> > >> regards, > >> Peter > >> > >>> > >>> Best regards, > >>> Xiaohu > >>> > >>>> regards, > >>>> Peter > >>>> > >>>> > >>>> > >>>> On 1/27/14 04:34 , Xuxiaohu wrote: > >>>>> Hi all, > >>>>> > >>>>> Any comments are welcome. > >>>>> > >>>>> Best regards, > >>>>> Xiaohu > >>>>> > >>>>>> -----邮件原件----- > >>>>>> 发件人: [email protected] [mailto:[email protected]] > >>>>>> 发送时间: 2014年1月21日 13:53 > >>>>>> 收件人: Mach Chen; Mach Chen; Xuxiaohu; Xuxiaohu > >>>>>> 主题: New Version Notification for > >>>>>> draft-xu-ospf-global-label-sid-adv-00.txt > >>>>>> > >>>>>> > >>>>>> A new version of I-D, draft-xu-ospf-global-label-sid-adv-00.txt > >>>>>> has been successfully submitted by Xiaohu Xu and posted to the > >>>>>> IETF > >>>> repository. > >>>>>> > >>>>>> Name: draft-xu-ospf-global-label-sid-adv > >>>>>> Revision: 00 > >>>>>> Title: Advertising Global Labels or SIDs Using OSPF > >>>>>> Document date: 2014-01-21 > >>>>>> Group: Individual Submission > >>>>>> Pages: 7 > >>>>>> URL: > >>>>>> http://www.ietf.org/internet-drafts/draft-xu-ospf-global-label-si > >>>>>> d- > >>>>>> ad > >>>>>> v-00.txt > >>>>>> Status: > >>>>>> https://datatracker.ietf.org/doc/draft-xu-ospf-global-label-sid-a > >>>>>> dv > >>>>>> / > >>>>>> Htmlized: > >>>>>> http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00 > >>>>>> > >>>>>> > >>>>>> Abstract: > >>>>>> Segment Routing (SR) is a new MPLS paradigm in which each > >>>> SR-capable > >>>>>> router is required to advertise global MPLS labels or Segment > IDs > >>>>>> (SID) for its attached prefixes by using link-state IGPs, e.g., > >>>>>> OSPF. > >>>>>> One major challenge associated with such global MPLS label or > SID > >>>>>> advertisement mechanism is how to avoid a given global MPLS > >>>>>> label > >> or > >>>>>> SID from being allocated by different routers to different > prefixes. > >>>>>> Although such global label or SID allocation collision problem > can be > >>>>>> addressed through manual allocation , it is error-prone and > >>>>>> nonautomatic therefore may not be suitable in large-scale > >>>>>> SR > >> network > >>>>>> environments. This document proposes an alternative > >>>>>> approach > >> for > >>>>>> allocating and advertising global MPLS labels or SIDs via OSPF so > as > >>>>>> to eliminate the potential risk of label allocation collision. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Please note that it may take a couple of minutes from the time of > >>>>>> submission until the htmlized version and diff are available at > tools.ietf.org. > >>>>>> > >>>>>> The IETF Secretariat > >>>>> > >>>>> _______________________________________________ > >>>>> OSPF mailing list > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/ospf > >>>>> > >>> > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
