[mpls-tp] Query on the mismatch of draft-ietf-mpls-tp-identifiers-04 and draft-ietf-ccamp-mpls-tp-cp-framework-06

zhang.fei3@zte.com.cn Mon, 21 March 2011 04:19 UTC

Return-Path: <zhang.fei3@zte.com.cn>
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 B783B3A65A5; Sun, 20 Mar 2011 21:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.712
X-Spam-Level:
X-Spam-Status: No, score=-100.712 tagged_above=-999 required=5 tests=[AWL=1.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
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 zG5p1LLKOwro; Sun, 20 Mar 2011 21:19:24 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 803EA3A6405; Sun, 20 Mar 2011 21:19:23 -0700 (PDT)
Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35102043691617; Mon, 21 Mar 2011 12:18:31 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.6608455112; Mon, 21 Mar 2011 12:20:17 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2L4K6Fc020799; Mon, 21 Mar 2011 12:20:07 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
To: matthew.bocci@alcatel-lucent.com, swallow@cisco.com, eric.gray@ericsson.com, loa.andersson@ericsson.com, lberger@labn.net, lufang@cisco.com, nabil.n.bitar@verizon.com, mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org
MIME-Version: 1.0
X-KeepSent: 3561E763:B9BE287F-4825785A:000F8990; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF3561E763.B9BE287F-ON4825785A.000F8990-4825785A.0017CE41@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Mon, 21 Mar 2011 12:20:12 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-21 12:20:07, Serialize complete at 2011-03-21 12:20:07
Content-Type: multipart/alternative; boundary="=_alternative 0017CE3C4825785A_="
X-MAIL: mse02.zte.com.cn p2L4K6Fc020799
Subject: [mpls-tp] Query on the mismatch of draft-ietf-mpls-tp-identifiers-04 and draft-ietf-ccamp-mpls-tp-cp-framework-06
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, 21 Mar 2011 04:19:25 -0000

Hi all

I have read the draft draft-ietf-mpls-tp-identifiers-04 recently, and the 
identifer of a co-routed bidirectioanl LSP is described in section 5.2.1, 
whose format is: 
East-Node_ID::East-Tunnel_Num::West-Node_ID::West-Tunnel_Num::LSP_Num

I agree that the introduction of West-Tunnel_Num is convenient for the 
acess of bidirectional services, which is described clearly in the first 
paragraph of secion 5:(A transport service may be composed of multiple 
LSPs. Further the LSPs providing a service may change over time due to 
protection and restoration events.  In order to clearly identify the 
service we use the term "MPLS-TP Tunnel" or simply "tunnel" for a service 
provided by (for example) a working LSP and protected by a protection 
LSP.)

The establishment of co-routed bidirectional LSP is based on the 
[RFC3473], but the current solution is not enough if West_Tunnel_Num is 
introduced. (draft-ietf-ccamp-mpls-tp-cp-framework-06 did not catch the 
gaps up to now.)

Following is the format of the Session Object, Sender Template Object, and 
Session Attribute Object (cited from RFC3209 for reference)

   Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7 

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 tunnel end point address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MUST be zero                 |      Tunnel ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Extended Tunnel ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 tunnel sender address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MUST be zero                 |            LSP ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Setup Prio  | Holding Prio  |     Flags     |  Name Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //          Session Name      (NULL padded display string)      //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As we can see, there is no field to fill the West-Tunnel_Num. Fortunately, 
this can be easily achieved by defining a new C-type in Session Class. For 
example,

the format for the new C-type is below (of course, a new defined object is 
possible):

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 tunnel end point address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  West-Tunnel_Num              |      Tunnel ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Extended Tunnel ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In conclusion:

(1) The West-Tunnel_Num defined in draft-ietf-mpls-tp-identifiers-04 is 
useful, but draft-ietf-ccamp-mpls-tp-cp-framework-06 SHOULD catch the 
gaps.

(2) The establishment of MPLS-TP co-routed bidirectional SHOULD be 
described cleary by a individual document or any other existing documents.

Just my two cents

Fei