[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [OSPF] fwd: New Version Notification for draft-xu-ospf-global-label-sid-adv-00.txt
From: Xuxiaohu <xuxiaohu () huawei ! com>
Date: 2014-01-29 8:53:22
Message-ID: 1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824948F () NKGEML512-MBS ! china ! huawei ! com
[Download RAW message or body]
> -----邮件原件-----
> 发件人: spring [mailto:spring-bounces@ietf.org] 代表 Xuxiaohu
> 发送时间: 2014年1月29日 12:02
> 收件人: Peter Psenak
> 抄送: ospf@ietf.org; spring@ietf.org
> 主题: Re: [spring] [OSPF] fwd: New Version Notification for
> draft-xu-ospf-global-label-sid-adv-00.txt
>
> Hi Peter,
>
> > -----邮件原件-----
> > 发件人: Peter Psenak [mailto:ppsenak@cisco.com]
> > 发送时间: 2014年1月27日 18:08
> > 收件人: Xuxiaohu
> > 抄送: spring@ietf.org; ospf@ietf.org
> > 主题: 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:ppsenak@cisco.com]
> > > > 发送时间: 2014年1月27日 16:41
> > > > 收件人: Xuxiaohu
> > > > 抄送: spring@ietf.org; ospf@ietf.org
> > > > 主题: 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
> > > > >
> > > > > > -----邮件原件-----
> > > > > > 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > > > 发送时间: 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
> > > > > OSPF@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/ospf
> > > > >
> > >
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic