[mpls] 答复: Comments on draft-li-mpls-global-label-usecases

Lizhenbin <lizhenbin@huawei.com> Tue, 29 July 2014 08:30 UTC

Return-Path: <lizhenbin@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131B51A00AD for <mpls@ietfa.amsl.com>; Tue, 29 Jul 2014 01:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.748
X-Spam-Level: *
X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtDDQ2jzJO8D for <mpls@ietfa.amsl.com>; Tue, 29 Jul 2014 01:30:14 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D93F1A02C2 for <mpls@ietf.org>; Tue, 29 Jul 2014 01:30:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHR80602; Tue, 29 Jul 2014 08:30:12 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 09:30:11 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 16:30:06 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, "draft-li-mpls-global-label-usecases@tools.ietf.org" <draft-li-mpls-global-label-usecases@tools.ietf.org>
Thread-Topic: Comments on draft-li-mpls-global-label-usecases
Thread-Index: Ac+pyGOnOvdR466BTIiQqApCOmu/xgBMxX8p
Date: Tue, 29 Jul 2014 08:30:05 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08233D1D@nkgeml506-mbx.china.huawei.com>
References: <CECE764681BE964CBE1DFF78F3CDD3941E272EEB@xmb-aln-x01.cisco.com>
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E272EEB@xmb-aln-x01.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.216.45.77]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9colOiDEnXrZ6OsdxIvMYZI4_uI
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] 答复: Comments on draft-li-mpls-global-label-usecases
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jul 2014 08:30:20 -0000

Hi Nobo,
Thanks very much for your detailed my comments. Pleaser refer to my inline reply.

Best Regards,
Robin


________________________________________
发件人: Nobo Akiya (nobo) [nobo@cisco.com]
发送时间: 2014年7月28日 3:05
收件人: draft-li-mpls-global-label-usecases@tools.ietf.org
抄送: mpls@ietf.org
主题: Comments on draft-li-mpls-global-label-usecases

Hi Authors,

The presentation for this document at IETF90 added some use cases.

http://www.ietf.org/proceedings/90/slides/slides-90-mpls-13.pptx, Slide 2.

Below are my comments on just the new use cases added.

1. MPLS OAM for LDP LSP

The problem isn't specific to LDP, but SR as well as TE/TP with PHP. 
[Robin] I agree with you that the problem also exists with MPLS TE with PHP. But for MPLS TP, it excludes PHP, so it is not an issue for MPLS TP:)
However, what you need is a label that ingress and egress agree on, which granularity is likely at least one label per LSP. 
[Robin] The granularity is not this way you mentioned. It is just to allocate a unique global label for each PE node in the network . When send packet, it will use the label stack (label for the LSP + label for the PE).  So the egress node can count the packet for the flow from a specific PE for a specific prefix. There are not many PE nodes in the network. So it will not burn up the labels. 
Attempting to solve this through suggested "global label" will unnecessary burn up labels in the "global label space" (i.e. severe scalability problem). In other words, LSP egress allocated context label appears to be simpler and technical superior, IMHO.
[Robin] I think global label and context label is not the parallel concept. I have explained it in the draft draft-li-mpls-global-label-framework. MPLS global label can be allocated from the per-platform label space or the context-specific label space. No matter which label space, if the meaning of the label can be understand by multiple nodes, it should be called as the global label. In this use case, the global label for the source PE node can be allocated from the context-based label space.  Since its meaning to identify a specific PE should be understood by all involved nodes in the network, it is the global label.


2. Service Chaining

Why not let SFC folks to do their work, which SFC will then work on the MPLS data plane without any changes to the MPLS data plane nor architecture, certainly doesn't require any "global label" as this use case is describing. Unless the SFC WG require the "global label" (which it doesn't) or the MPLS WG is re-chartered to pick up creation of a tangent SFC solution specifically for MPLS, I don't think this use case is valid.
[Robin] SFC WG truly works on some new header for service functions. We need to work out the when MPLS dataplane applied, what the possible problem and the solution. I think MPLS has been widely deployed in the existing network and SFC is the possible useful use case in MPLS network which should be taken into account in the MPLS world. MPLS global label is one of the possible solutions. This does not preclude other solutions.

3. Segment Routing

The Segment Routing technology is much further down the road (i.e. we even saw some cool stuff in the Bits-n-Bites at IETF90) and they already have a solution for SRGB. Even if Segment Routing was using global labels (which isn't the case), I'm not sure if there's any value in listing this as a use case for "global label".
[Robin] SRGB is the solution. But what is the global unique segement identifier in the segment routing? Do you think the network administrator will configure distinct SRGBs for all nodes, node 1 use SRGB [100, 200], node 2 use SRGB [200, 300], node 3 use SRGB [300, 400], etc.? I think this way may be crazy. The simplest way is just to configure the SAME SRGB as much as possible. Moreover, if all SRGBs in the nodes begin from 0, what is the difference between the global unique segment identifier and the global label? No matter global SID for global label, SR needs a global identifier which needs to be advertised to all nodes in the network. I think the global label is the direct way. SRGB is just an indirect way to force the global identifier to becomes a form of local label. That is it!


I've only had a quick scan of draft-li-mpls-global-label-usecases (and haven't fully read all the referenced documents), but my immediate reaction was "are these real use cases?"
[Robin] I understand you reaction and I hope you can read the usecase and the possible reference documents. In fact, these problem statement or usecase proposed here already exists in some RFC or WG drafts. But in these documents, the solutions may be called as other name which in my opinion is one type of global lablel or it adopts complex way to solve the issue which in my opinion can be easily solved if global label is adopted.

Perhaps there's a value is re-writing this documents to exclude following categories:
- This can become a use case if folks didn't want to use context labels.
[Robin] I have explained it.Per-platform and context-specific are the parallel concepts to divide MPLS into two. Local and global label are another parrallel concepts to divide MPLS into two. Even if context lael is used, it should also be called as global label if it has global meaning. 
- This can become a use case if things like this was ever required.
[Robin] Partly agree. I rembers one thing Ford (founder of Ford car ) said that if I asked people what required, they may say a faster horse instead of car. 
- This can become a use case but there are solutions out there already.
[Robin] Partly agree. MPLS TE does work and has been deployed widely. Why segment routing?
[Robin] Regarding the latter two, my opinion is that we need to change with time. 


b
My 2 yen.

Thanks!

-Nobo