[Status] 答复: 答复: fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt
Xuxiaohu <xuxiaohu@huawei.com> Thu, 25 July 2013 08:43 UTC
Return-Path: <xuxiaohu@huawei.com>
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0507421F9C32 for <status@ietfa.amsl.com>; Thu, 25 Jul 2013 01:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.131
X-Spam-Level:
X-Spam-Status: No, score=-5.131 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kHNG8ZfzmcD for <status@ietfa.amsl.com>; Thu, 25 Jul 2013 01:43:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEF421F9C06 for <status@ietf.org>; Thu, 25 Jul 2013 01:43:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATT81115; Thu, 25 Jul 2013 08:43:17 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 09:42:59 +0100
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 09:43:13 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 25 Jul 2013 16:43:08 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Hannes Gredler <hannes@juniper.net>
Thread-Topic: [Status] 答复: fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt
Thread-Index: AQHOiQ/VOPWxknVPyEiUuWZEo8V/+pl1ErEg
Date: Thu, 25 Jul 2013 08:43:07 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D8C82@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6FDB@NKGEML512-MBS.china.huawei.com> <51E90059.1090701@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D7077@NKGEML512-MBS.china.huawei.com> <51E9112E.6020803@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D73A1@NKGEML512-MBS.china.huawei.com> <51ED124A.7030204@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80C8@NKGEML512-MBS.china.huawei.com> <48BE96C3-7665-4441-A6DE-FA139F78D0F7@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D8C55@NKGEML512-MBS.china.huawei.com> <5AF8B30E-E460-480B-83AF-0FBA4A367409@juniper.net>
In-Reply-To: <5AF8B30E-E460-480B-83AF-0FBA4A367409@juniper.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.130]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "status@ietf.org" <status@ietf.org>, Robert Raszuk <robert@raszuk.net>, Peter Psenak <ppsenak@cisco.com>
Subject: [Status] 答复: 答复: fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/status>, <mailto:status-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/status>
List-Post: <mailto:status@ietf.org>
List-Help: <mailto:status-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/status>, <mailto:status-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 08:43:39 -0000
> -----邮件原件----- > 发件人: 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. 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] fwd: New Version Notification for draft-… Xuxiaohu
- Re: [Status] fwd: New Version Notification for dr… Saku Ytti
- Re: [Status] fwd: New Version Notification for dr… Peter Psenak
- Re: [Status] fwd: New Version Notification for dr… Xuxiaohu
- Re: [Status] fwd: New Version Notification for dr… Peter Psenak
- Re: [Status] fwd: New Version Notification for dr… Xuxiaohu
- Re: [Status] fwd: New Version Notification for dr… Peter Psenak
- [Status] 答复: fwd: New Version Notification for dr… Xuxiaohu
- Re: [Status] 答复: fwd: New Version Notification fo… Peter Psenak
- [Status] 答复: 答复: fwd: New Version Notification fo… Xuxiaohu
- Re: [Status] fwd: New Version Notification for dr… Xuxiaohu
- Re: [Status] fwd: New Version Notification for dr… Hannes Gredler
- [Status] 答复: fwd: New Version Notification for dr… Xuxiaohu
- Re: [Status] 答复: fwd: New Version Notification fo… Hannes Gredler
- Re: [Status] 答复: fwd: New Version Notification fo… Robert Raszuk
- [Status] 答复: 答复: fwd: New Version Notification fo… Xuxiaohu
- [Status] 答复: 答复: 答复: fwd: New Version Notificatio… Xuxiaohu
- Re: [Status] 答复: 答复: 答复: fwd: New Version Notific… Robert Raszuk
- [Status] 答复: 答复: 答复: 答复: fwd: New Version Notific… Xuxiaohu
- Re: [Status] 答复: 答复: fwd: New Version Notificatio… Hannes Gredler
- Re: [Status] 答复: 答复: 答复: fwd: New Version Notific… Hannes Gredler