Re: [OSPF] fwd: New Version Notification for draft-xu-ospf-global-label-sid-adv-00.txt

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: spring [mailto:[e-mail]] 代表 Xuxiaohu
> 发送时间: 2014年1月29日 12:02
> 收件人: Peter Psenak
> 抄送: [e-mail]; [e-mail]
> 主题: Re: [spring] [OSPF] fwd: New Version Notification for
> draft-xu-ospf-global-label-sid-adv-00.txt
> 
> Hi Peter,
> 
> > -----邮件原件-----
> > 发件人: Peter Psenak [mailto:[e-mail]]
> > 发送时间: 2014年1月27日 18:08
> > 收件人: Xuxiaohu
> > 抄送: [e-mail]; [e-mail]
> > 主题: 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:[e-mail]]
> > >> 发送时间: 2014年1月27日 16:41
> > >> 收件人: Xuxiaohu
> > >> 抄送: [e-mail]; [e-mail]
> > >> 主题: 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.
> >
> > >
> > >     "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.
> 
> According to the following text quoted from ISIS SR draft,
> 
> "Segment Routing requires each router to advertise its SR data-plane
>    capability and the range of SID/Label values it uses for Segment
>    Routing."
> 
> If you advertise the label range starting from 0, does that mean the reserved
> label block of 0-15 is also used for segment routing? IMO, as long as it's possible
> for most SR routers to allocate a common label block for SR purpose, the global
> label should be advertised in the control plane. For those seldom SR nodes which
> could not allocate that label block, the global label advertised in the control
> plane would be used to determine the corresponding local label which is used in
> the data plane.

For example, assume a label block {1000, 1999} is allocated for prefix segments by almost all SR routers and a global label 1005 is allocated to a given prefix segment, for a given seldom SR router which couldn't preserve the above label block and allocates a different label block (e.g., {2000, 2999}) instead, a local label corresponding to that global label (or that prefix segment) could be calculated through offsetting, i.e., the result is 1005+ (2000-1000)=2005. In this way, there is no need for introducing the Index concept anymore and therefore the architecture becomes much easy to understand. More importantly, compared to the index binding advertisement, the label binding advertised by the IGP is exactly the same as that in the label forwarding table for those most SR routers which have allocated the above common label block, which is much beneficial when doing troubleshooting. This approach does not violate the strongest MPLS dogma (i.e., labels MUST be local) while taking into account the actual situation, IMHO

Best regards,
Xiaohu

> 
> 
> > >> 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
> > >>>
> > >>>> -----邮件原件-----
> > >>>> 发件人: [e-mail] [mailto:[e-mail]]
> > >>>> 发送时间: 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
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/ospf
> > >>>
> > >
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring