On Jan 27, 2014, at 11:03 AM, Xuxiaohu wrote: > > >> -----邮件原件----- >> 发件人: Stefano Previdi (sprevidi) [mailto:[email protected]] >> 发送时间: 2014年1月27日 17:54 >> 收件人: Xuxiaohu >> 抄送: Peter Psenak (ppsenak); [email protected]; [email protected] >> 主题: Re: [OSPF] New Version Notification for >> draft-xu-ospf-global-label-sid-adv-00.txt >> >> On Jan 27, 2014, at 10:49 AM, 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. >> >> >> As it is defined now, there is nothing that prevents the MS to be used for >> mapping SIDs/labels to indistinctly SR and non-SR routers. > > Hi, > > "Segment Routing requires each router to advertise its SR data-plane > capability and the range of SID/Label values it uses for Segment > Routing. Data-plane capabilities and SID/Label ranges are advertised > using the newly defined SR-Capabilities Sub-TLV inserted into the > IS-IS Router Capability TLV-242 that is defined in [RFC4971]. " -quoted > from your ISIS extension for SR draft. > > I understand that the MS could be used to advertise indexes on behalf of SR > routers. However, I wonder whether the MS could also be used to advertise the > SID/label range on behalf of SR routers according to the above specification.
it can. Maybe we can add some more words. s. > > Best regards, > Xiaohu > >> s. >> >> >>> 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. >>> >>> "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. >>> >>>> 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. >>> >>> 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-sid- >>>>>> ad >>>>>> v-00.txt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-xu-ospf-global-label-sid-adv >>>>>> / >>>>>> 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 > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
