> -----邮件原件----- > 发件人: 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. 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
