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

From: [email-masked]
Date: Mon, 21 Mar 2011 12:20:12 +0800

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