Re: [mpls] I-D Action:draft-ietf-mpls-tp-identifiers-02.txt

venkatesan mahalingam <venkatflex@gmail.com> Tue, 13 July 2010 15:43 UTC

Return-Path: <venkatflex@gmail.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BACB3A6818; Tue, 13 Jul 2010 08:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.448
X-Spam-Level:
X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3]
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 fkqCFiUiAb8Q; Tue, 13 Jul 2010 08:43:06 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 802E03A6B2E; Tue, 13 Jul 2010 08:42:43 -0700 (PDT)
Received: by pzk6 with SMTP id 6so1731327pzk.31 for <multiple recipients>; Tue, 13 Jul 2010 08:42:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=X1CTMdrPiEpjBO2n9Z1Kggkjhz+zqH7uqAddy/mQTZU=; b=Vf0FNzWuLbY8z35O/Yp8t4flxEj996T3QDssj6lSnhAYTP3nWWKq1obVt042yiVyE/ R8r96LEEq+PNyMPZULJUZZGVBmeYPmowbX93Ygqfr9c8t41ej95kMKf3TAEVIeg7SrTL CJzM4WGbNnLxD0qZ8tUiGQbbwBhQW/GnmdNCI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=r7Yrtt8LkdE6szeoFYlBywnBXpfekpCJ7onm2c34amb7IopV9D436Q3MGwccT+mLTc 97m9oXxD99ounneBfExgNoFFKIHSRTKHu87dTeHiFuEJkfeo+0VjeRQNZQZHh970pkjP 4Ux/zld12P/NcJ//dQAy6sn+m19Iy1jESBBQA=
MIME-Version: 1.0
Received: by 10.142.73.1 with SMTP id v1mr18293362wfa.29.1279035758954; Tue, 13 Jul 2010 08:42:38 -0700 (PDT)
Received: by 10.143.167.14 with HTTP; Tue, 13 Jul 2010 08:42:38 -0700 (PDT)
In-Reply-To: <20100712233030.67F423A68DA@core3.amsl.com>
References: <20100712233030.67F423A68DA@core3.amsl.com>
Date: Tue, 13 Jul 2010 21:12:38 +0530
Message-ID: <AANLkTilqobseCxAIZMh6bPGM8YPOSbOBAzKMIgn6giie@mail.gmail.com>
From: venkatesan mahalingam <venkatflex@gmail.com>
To: George Swallow <swallow@cisco.com>, mpls <mpls@ietf.org>, mpls-tp@ietf.org
Content-Type: multipart/alternative; boundary="001636ed675813fca6048b46b80d"
Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-identifiers-02.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 13 Jul 2010 15:43:08 -0000

George,

Please find the comments inlined <VM> on this MPLS_TP identifiers draft,

Section 5.1.  MPLS-TP Point to Point Tunnel Identifiers
It is RECOMMENDED that the IF_Num be auto-generated by adding
   2^31 to the local Tunnel_Num

<VM> What was the intention to auto-generate IF_Num by adding 2^31 to the
local Tunnel_Num?

7.2.2.2.  MEP_IDs for Pseudowires
 where the Node_ID is the node in which the MEP is located and
   Tunnel_Num is the tunnel number unique to that node.
<VM> Typo error, please correct it.

 6.  Pseudowire Path Identifiers

      AGI:Src-Global_ID::Src-Node_ID::Src-AC_ID::Dst-Global_ID::
      Dst-Node_ID::Dst-AC_ID
<VM> Does FEC 129 AII Type 2 configuration applicable for both manual and
signalling PWs?
     How to represent this AC_ID in the PW mibs? Will there be any
augmentation in the PW AC mibs (PW-ENET-STD-MIB)?

GS: In Stockholm I was convinced that for ICC based identifiers, only the
MEG-ID and/or ME-ID would need to be configured at various points along an
LSP.  Much has changed on this project since then.  Is what we have not
sufficient?

<VM>  What I infer from your response is, ICC based identifiers are
applicable only for the MEG-ID and/or ME-ID identification. So, does it mean
that ICC based operator environment also, MPLS-TP LSP will be created using
Global_ID? If the answer is yes, i.e Global_Id and ICC should co-exist for
creating/monitoring the MPLS-TP tunnel, in that case can't we completely
eliminate the need of ICC based identifier and Global_ID identifier can
alone be used for creating/monitoring the MPLS-TP tunnel?

 7.1.2.1.  MPLS-TP LSP MEG_IDs
 Since a MEG pertains to a single MPLS-TP LSP, IP compatible MEG_IDs
   for MPLS-TP LSPs are simply the corresponding LSP_IDs

<VM> For uni-directional/bi-directional tunnel, one MEG is associated with
only one LSP (ME).
For P2MP unidirectional tunnel, one MEG is associated with multiple
destination LSPs (MEs)
Is this understanding correct?

<VM> How to configure multiple client MEGs in a server MEG? I believe, we
don't follow the ITU-T Y1731 MEG level concept in MPLS-TP. Please give us
some insight into the client MEG and server MEG handling for MPLS-TP.

 >> 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.

<VM> I agree with Mach Chen for two LSP_Nums for associated bi-directional
tunnel,

For example, consider the below topology,

All routers are in different Global_ID operators domain.

  R1-----R2---------R3
  |                       |
  |______R4_____|

Tunnel LSP identifier:
Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::Dst-Tunnel_Num::LSP_Num

Co-routed bi-directional tunnel:
Co-routed bi-directional tunnel (Tnl_Num=100, LSP_Num=1, Src=R1, Dst=R3) is
established from R1 to R3 via R2.
Forward and reverse directions LSP identifier: G1_R1::100::G3_R3::100::1

Associated bi-directional tunnel:
Associated bi-directional tunnel is established from R1 to R3 via R2 for
forward direction.
For this forward direction, LSP identifier is: G1_R1::100::G3_R3::200::*1
*For reverse direction, a LSP from R3 to R1 via R4 may exist.
For this reverse direction LSP identifier: G3_R3::200::G1_R1::100::*2
*

If I assume that the above scenario is valid, we can combine these two
different LSPs as a single bidirectional LSP only when we have two LSP_Nums.

IMO, two LSP_Nums are required to identify the reverse direction tunnel from
the forward direction tunnel identifiers and vice versa.

If we want to combine them as single LSP identifier, the LSP identifier
should be as follows.

Tunnel LSP identifier:
Src-Global_Node_ID::Src-Tunnel_Num::Src-LSP_Num::Dst-Global_Node_ID::Dst-Tunnel_Num::Dst-LSP_Num

Example: G1_R1::100::*1*::G3_R3::200::*2*

Please correct me if I'm wrong in the understanding.

BR,

Venkat.

On Tue, Jul 13, 2010 at 5:00 AM, <Internet-Drafts@ietf.org> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiprotocol Label Switching Working
> Group of the IETF.
>
>
>        Title           : MPLS-TP Identifiers
>        Author(s)       : M. Bocci, G. Swallow
>        Filename        : draft-ietf-mpls-tp-identifiers-02.txt
>        Pages           : 14
>        Date            : 2010-07-12
>
> This document specifies identifiers for MPLS-TP objects.  Included
> are identifiers conformant to existing ITU conventions and
> identifiers which are compatible with existing IP, MPLS, GMPLS, and
> Pseudowire definitions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-identifiers-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>


-- 
Best Regards,
Venkatesan Mahalingam.