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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: Hannes Gredler [mailto:[e-mail]]
> 发送时间: 2013年7月25日 16:20
> 收件人: Xuxiaohu
> 抄送: [e-mail]; 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:[e-mail]]
> >> 发送时间: 2013年7月25日 15:40
> >> 收件人: Xuxiaohu
> >> 抄送: Peter Psenak; [e-mail]; 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.

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:[e-mail]]
> >>>> 发送时间: 2013年7月22日 19:07
> >>>> 收件人: Xuxiaohu
> >>>> 抄送: [e-mail]
> >>>> 主题: 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/status
> >>
> >>
> >
> > _______________________________________________
> > status mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/status
> 
>