Re: [mpls-tp] Comments on draft-ietf-mpls-tp-identifiers-01

George Swallow <swallow@cisco.com> Mon, 12 July 2010 20:48 UTC

Return-Path: <swallow@cisco.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 6328C3A6C30 for <mpls-tp@core3.amsl.com>; Mon, 12 Jul 2010 13:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.075
X-Spam-Level:
X-Spam-Status: No, score=-10.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 wtQicphY8Vfp for <mpls-tp@core3.amsl.com>; Mon, 12 Jul 2010 13:48:40 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 43B593A6C2E for <mpls-tp@ietf.org>; Mon, 12 Jul 2010 13:48:40 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEACIcO0ytJV2Y/2dsb2JhbACgOXGlAZp6hScEiEyCLg
X-IronPort-AV: E=Sophos;i="4.55,190,1278288000"; d="scan'208";a="131510363"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 20:48:48 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o6CKmlLG017777; Mon, 12 Jul 2010 20:48:47 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 15:48:48 -0500
Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Jul 2010 20:48:47 +0000
User-Agent: Microsoft-Entourage/12.25.0.100505
Date: Mon, 12 Jul 2010 16:48:46 -0400
From: George Swallow <swallow@cisco.com>
To: Mach Chen <mach@huawei.com>, <mpls-tp@ietf.org>
Message-ID: <C860F7EE.275E6%swallow@cisco.com>
Thread-Topic: [mpls-tp] Comments on draft-ietf-mpls-tp-identifiers-01
Thread-Index: AcsiA58ejsR0zoi4t0u2BRuXS/4/jQ==
In-Reply-To: <183D297F2403463FAE3475F1673BF925@m55527c>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Jul 2010 20:48:48.0217 (UTC) FILETIME=[A0709490:01CB2203]
Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-identifiers-01
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: Mon, 12 Jul 2010 20:48:41 -0000

Mach -


On 6/21/10 11:47 PM, "Mach Chen" <mach@huawei.com> wrote:

> Hi authors,
> 
> Here are some comments:
> 
> 1. In the draft, the Source/Destination Node is defined as a 32-bits ID, but
> for a MPLS/GMPLS TE based LSP, the Tunnel Extended ID, Tunnel end point
> address and Tunnel sender address may be IPv6 addresses, it seems that the
> "mapping to GMPLS signaling" (Section 5.3) can not handle this.

I was thinking that for IPv6 we could use the embedded IPv4 format:

0:0:0:0:0:FFFF:Node-ID.

Of course there are other ways of handling this.  We *could* define new
session, sender-template, and filter-spec objects that are specifically
defined as MPLS-TP node-IDs.

 
> 2. In your draft, an LSP is identified by the combination of Src-Global_ID,
> Src-Node_ID, Src-Tunnel_Num, Dst-Global_ID, Dst-Node_ID, Dst-Tunnel_Num,
> LSP_Num, this is fine for unidirectional and co-routed bidirectional LSP,
> but it is not enough for associated bidirectional LSP that is combined with
> two reverse unidirectional LSPs and IMHO two LSP_Nums are required.

We should discuss this (and the above if you like) in Maastricht.

...George

> Best regards,
> Mach 
> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp