[Status] 答复: 答复: 答复: fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

> -----邮件原件-----
> 发件人: status-bounces@ietf.org [mailto:status-bounces@ietf.org] 代表
> Xuxiaohu
> 发送时间: 2013年7月25日 16:43
> 收件人: Hannes Gredler
> 抄送: status@ietf.org; Robert Raszuk; Peter Psenak
> 主题: [Status] 答复: 答复: fwd: New Version Notification for
> draft-xu-rtgwg-global-label-adv-00.txt
> 
> 
> 
> > -----邮件原件-----
> > 发件人: Hannes Gredler [mailto:hannes@juniper.net]
> > 发送时间: 2013年7月25日 16:20
> > 收件人: Xuxiaohu
> > 抄送: status@ietf.org; Robert Raszuk; Peter Psenak
> > 主题: Re: [Status] 答复: fwd: New Version Notification for
> > draft-xu-rtgwg-global-label-adv-00.txt
> >
> >
> > On Jul 25, 2013, at 10:07 AM, Xuxiaohu wrote:
> >
> > > Hi Hannes,
> > >
> > >> -----邮件原件-----
> > >> 发件人: Hannes Gredler [mailto:hannes@juniper.net]
> > >> 发送时间: 2013年7月25日 15:40
> > >> 收件人: Xuxiaohu
> > >> 抄送: Peter Psenak; status@ietf.org; Robert Raszuk
> > >> 主题: Re: [Status] fwd: New Version Notification for
> > >> draft-xu-rtgwg-global-label-adv-00.txt
> > >>
> > >> xuxiaohu,
> > >>
> > >> the best proposal i have seen so far for resolving potential clashes
> > >> with global labels is roberts draft:
> > >>
> > >> http://tools.ietf.org/html/draft-raszuk-mpls-domain-wide-labels-00
> > >>
> > >> the draft proposes to use a context label for keying off in a separate
> > >> 'domain-wide' label space - i.e. no clash with anybody in the networking
> > >> doing local label allocation.
> > >
> > > Yes, there is no clash with existing transport or application labels which are
> > locally significant. However, you still need some mechanism to ensure that a
> > given domain-wide labels would not be assigned to different FECs (i.e.,
> different
> > node segments).
> >
> > yes and that mechanism is administrative policy. if you treat a MPLS
> > label as global identifier you have to ensure that it does
> > to get allocated twice.
> >
> > >> note that i am still not convinced that we need domain-wide labels
> > >> (if we have SPT labels as per the latest SR protocol extensions).
> > >
> > > What does the SPT label mean?
> >
> > an SPT label  is a label inside a label block. the actual label
> > is determined by an index advertised by egress routers.
> > the path to the egress router gets determined using an SPT
> > calculation.
> 
> It uses the trick which has been used by BGP-based VPLS solution. Interesting.

In this way, the labels would be locally significant. Then how to achieve source routing by using stacked MPLS tunnels ?

Xiaohu 

> Best regards,
> Xiaohu
> 
> > see
> >
> > http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-02
> > http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-extensions-02
> >
> > and
> >
> > http://tools.ietf.org/html/draft-gredler-isis-label-advertisement-03
> > http://tools.ietf.org/html/draft-gredler-ospf-label-advertisement-03
> >
> > for manifestations of this.
> >
> >
> > >> On Jul 23, 2013, at 3:06 AM, Xuxiaohu wrote:
> > >>
> > >>> Peter,
> > >>>
> > >>>> -----邮件原件-----
> > >>>> 发件人: Peter Psenak [mailto:ppsenak@cisco.com]
> > >>>> 发送时间: 2013年7月22日 19:07
> > >>>> 收件人: Xuxiaohu
> > >>>> 抄送: status@ietf.org
> > >>>> 主题: Re: [Status] fwd: New Version Notification for
> > >>>> draft-xu-rtgwg-global-label-adv-00.txt
> > >>>>
> > >>>> Xiaohu,
> > >>>>
> > >>>> On 7/22/13 05:19 , Xuxiaohu wrote:
> > >>>>
> > >>>>>>
> > >>>>>> - nothing in existing SR drafts prevents you to advertise SIDs/labels
> > >>>>>> from mapping server even for prefixes connected to SR capable
> > routers.
> > >>>>>
> > >>>>> Yes, it doesn't prevent that case explicitly. However, I haven't seen any
> > >>>> description of that case in the existing SR drafts.
> > >>>>
> > >>>> does not mean you can not do it.
> > >>>
> > >>>
> > >>>>>
> > >>>>> As you pointed out, the flooding scope of the OSPFv2 Extended Prefix
> > >> Opaque
> > >>>> DEPENDS on the content inside the LSA in the SR draft. However, In my
> > >> draft,
> > >>>> the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND
> on
> > the
> > >>>> content inside the LSA.
> > >>>>
> > >>>> given that OSPFv2 Extended Prefix Opaque LSA as defined in existing
> OSPF
> > >>>> SR draft allows you to do what you need, there is no need to define a
> > >>>> new LSA.
> > >>>
> > >>> The major difference lies in the TLVs and sub-TLVs contained in that prefix
> > >> specific opaque LSA rather than the opaque LSA itself which only needs a
> > >> Opaque type code to be assigned.
> > >>>
> > >>> Best regards,
> > >>> Xiaohu
> > >>>
> > >>>> regards,
> > >>>> Peter
> > >>>>
> > >>>>>
> > >>>>> Best regards,
> > >>>>> Xiaohu
> > >>>>>
> > >>>
> > >>> _______________________________________________
> > >>> status mailing list
> > >>> status@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/status
> > >>
> > >>
> > >
> > > _______________________________________________
> > > status mailing list
> > > status@ietf.org
> > > https://www.ietf.org/mailman/listinfo/status
> >
> >
> 
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status