Re: [mpls-tp] Early version of revised ITU-T Recommendation G.7712 including MPLS-TP
Dieter Beller <Dieter.Beller@alcatel-lucent.com> Fri, 09 April 2010 16:29 UTC
Return-Path: <dieter.beller@alcatel-lucent.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F923A68F6 for <mpls-tp@core3.amsl.com>; Fri, 9 Apr 2010 09:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.602
X-Spam-Level:
X-Spam-Status: No, score=-5.602 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWi7DoDPFK4U for <mpls-tp@core3.amsl.com>; Fri, 9 Apr 2010 09:28:59 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id E46F13A685D for <mpls-tp@ietf.org>; Fri, 9 Apr 2010 09:28:57 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o39GSpxQ015598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Apr 2010 18:28:51 +0200
Received: from [149.204.106.249] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.2.213.0; Fri, 9 Apr 2010 18:28:51 +0200
Message-ID: <4BBF55BF.1060006@alcatel-lucent.com>
Date: Fri, 09 Apr 2010 18:28:47 +0200
From: Dieter Beller <Dieter.Beller@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
References: <4B7E9EBB.5080102@alcatel-lucent.com> <8D8F155E589B4710AADFDFAC3C649990@your029b8cecfe>
In-Reply-To: <8D8F155E589B4710AADFDFAC3C649990@your029b8cecfe>
Content-Type: multipart/mixed; boundary="------------080909010902010307020701"
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Cc: "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] Early version of revised ITU-T Recommendation G.7712 including MPLS-TP
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 16:29:00 -0000
thanks for the comments - I will try to walk through them beginning of
next week and update the draft revision of G.7712. If some comments
are not clear we have to discuss them by correspondence as I will not be
in Stockholm next week. However, Kam will be there and may help
clarifying issues if necessary.
Cheers,
Dieter
On 09.04.2010 03:41, Adrian Farrel wrote:
Hi Dieter, Thanks for sharing this. Comments below are intended to help the drafting process and reach consesnsus more smoothly. Thanks, Adrian --- It looks like you've found and flagged nearly all the points where T-MPLS needs to be changed to MPLS-TP. I think it is as simple as, for example, OLD This 2008 revision of the Recommendation adds the requirements of the OTN ECC data-link layer termination function and the transport MPLS (T-MPLS) SCC data link layer termination function. NEW This 2010 revision of the Recommendation adds the requirements of the OTN ECC data-link layer termination function and the MPLS transport profile (MPLS-TP) SCC data link layer termination function. --- G.8121 is also listed in the References and will need to be updated. --- [IETF gach-dcn] can now be updated as: OLD [IETF gach-dcn] IETF Internet Draft draft-ietf-mpls-tp-gach-dcn-05.txt, An Inband Data Communication Network For the MPLS Transport Profile <draft-ietf-mpls-tp-gach-dcn-05.txt> NEW [IETF RFC 5718] IETF RFC 5718 (2009), An Inband Data Communication Network For the MPLS Transport Profile http://www.ietf.org/rfc/rfc4443.txt?number=5718" rel="nofollow">http://www.ietf.org/rfc/rfc4443.txt?number=5718. --- [IETF tp-cp-frwk] doesn't seem to be referenced, which is in as expected. So you can probably remove it from the References section. --- Section 7.1.1(e.g., [ITU-T G.783] (SDH), [ITU-T G.798] (OTH), [ITU-T G.8021] (Ethernet transport), and [ITU-T G.8121] (transport MPLS))Since these are examples, it may be easiest to change: OLD (e.g., [ITU-T G.783] (SDH), [ITU-T G.798] (OTH), [ITU-T G.8021] (Ethernet transport), and [ITU-T G.8121] (transport MPLS)) NEW (e.g., [ITU-T G.783] (SDH), [ITU-T G.798] (OTH), [ITU-T G.8021] (Ethernet transport), and MPLS-TP) --- Section 7.1.2.3.1When a shared trail SCN link is used, MPLS-TP cannot run in parallel with an IP (or other network layer network) user data plane over the same non- MPLS server layer trail.I don't agree with this. If you are saying this because you believe it to be a technical "cannot" then I think it is perfectly fine to send SCN IP packets addressed to the (e.g.) signaling controller and use this to distinguish the packets from others that should be forwarded or locally terminated. On the other hand, if you are saying that this is functional limitation, then you need "must not" and (of course) you need to provide a reference. --- 7.1.2.3.2 You have: This dedicated MPLS-TP trail cannot be used for user plane traffic I think you need "must not" instead of "cannot". If I recall OIF interop events, it is all too easy for user traffic to find its way onto the SCN! --- 7.1.2.5.1 You have: The layer-2 code-points (L2CPs, e.g., the EtherType field in case of an Ethernet PHY or the UPI field in case of GFP-F) are used to distinguish between the MPLS-TP LSPs, the MPLS-TP OAM forwarding including the MCC, and the packets destined for the SCC IP forwarding point or the SCC OSI forwarding point. This doesn't look right to me. We *do* distinguish native IP, OSI, and MPLS packets using L2 code points. We do not distinguish the content/use of those packets (user data, OAM, MCC, SCC) using L2 code points. And then: User traffic MPLS-TP LSPs (shown for the sake of completeness): I understand the completeness motivation, but user traffic is clearly out of scope of this Recommendation. Including any definitions here risks creating a second normative definition. Since the material is covered elsewhere, I suggest either completely dropping it, or inserting a Bibliographic reference. --- 7.1.15 I believe that most (all?) of this section is out of scope. The document is supposed to define the scope for the DCN. This section seems to try to define the operation of control plane signaling protocols and functions. We have plenty of work in both the IETF and the ITU-T on the control plane, and the details of the control plane operation will be specified in MPLS-TP RFCs. If it is necessary to set up MPLS-TP LSPs to establsh DCN connectivity, then this text should be generalized simply to say that the techniques used for LSP establishment may be used to set up such LSPs. --- 7.1.17 This looks very close to being out of scope. I guess that the DCN *might* require a path computation function. --- 7.1.19 This section is way out of scope! --- 7.3 This section looks rather empty! Are there really no other security requirements for the DCN? I thought SG17 had something to say on this topic. --- Annexes I know this material has been in 7712 for a while, but I am hugely worried by the fact that it is neither relevant to this document nor consistent with the IETF's copyright grants. I also believe that modifications to IETF protocol specifications should be conducted within the IETF. Discussion of this point is probably *way* outside the MPLS-TP discussions and I would welcome a private discussion with your Rapporteur about how we can resolve this issue.
- [mpls-tp] Early version of revised ITU-T Recommen… Dieter Beller
- [mpls-tp] Latest draft version of G.8110.1 (v1.7.… BUSI ITALO
- Re: [mpls-tp] Early version of revised ITU-T Reco… Adrian Farrel
- Re: [mpls-tp] Early version of revised ITU-T Reco… Dieter Beller