[mpls-tp] MPLS-TP identifiers clarification request

[venkatesan mahalingam <[e-mail]>]

Hi MPLS-TP group,
Please find below my comments in-line tagged VM>> on MPLS-TP identifiers.

As per George's response:
>>The draft defines the Global_Tunnel_ID as:
>>      Src-Global_ID::Src-Node_ID::Src-Tunnel_Num::
Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num

>>This seems to define a bidirectional tunnel. Is that the intent? If so
please clarify. If not then why

>>Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num is needed?

>>GS: The scope is bidirectional.  But I suppose it can be applied to
unidirectional as well.  I still don’t understand the requirement for

>>unidirectional – seems to be that bidirectional with 0 data-bandwidth in
the reverse direction would do better as you would have a return

>>path for OAM and DCC etc.

VM>> Don't we need uni-directional tunnel for MPLS-TP if the scope is
bi-directional?

If the answer yes, then do we need to remove the below requirements of an
MPLS-TP from the RFC-5654.
Section 2.1.  General Requirements
   7.   MPLS-TP MUST support unidirectional, co-routed bidirectional, and
       associated bidirectional point-to-point transport paths.

   8.   MPLS-TP MUST support unidirectional point-to-multipoint transport
       paths.


As per Mach Chen's mail dated Tue, 22 Jun 2010 11:47:17 +0800
>>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.

VM>> IMHO, we need two LSP_Nums for co-routed bidirectional LSP for
unidirectional protection switching i.e only forward or reverse direction

LSP protection switching instead of switching both forward and reverse
direction working LSP into protection LSP.
So, I think we need a single LSP_Num for unidirectional LSP, two LSP_Nums
for forward and reverse direction co-routed/associated MPLS-TP

tunnel.

Can we have two tunnels created independenly and have an association with
them for both co-routed and associated bi-directional MPLS-TP

tunnel?

As per Mukund's mail dated Fri, 28 May 2010 12:06:37 +0530
>>The "draft-ietf-mpls-tp-identifiers" mention two forms of operator
identification - Global_ID (for IP operational practice) and ICC

(compatible with ITU).
>>All the sections on identifiers further in the draft, mention the globally
unique format of the identifiers by pre-pending the Global_ID.

i.e they mention only the IP based identifiers.
>>Eg; For LSP Identiffication:
>>"Src-Global_ID::Src-Node_ID::Src-Tunnel_Num::
Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num::LSP_Num"
>>Shouldnt the draft be mentioning the ICC based identification also
(substituting Global_ID by ICC for ICC based LSP Identifiers) or

mentioning explicitly in the draft as follows:
>>"Src-Operator_ID::Src-Node_ID::Src-Tunnel_Num::Dst-Operator_ID::Dst-Node_ID::Dst-Tunnel_Num::LSP_Num"
>>Where Operator_ID can be Global_ID or ICC_ID
>> Or is it expected that for ICC based identification, different set of
identifiers will be defined similar to the MEG & MEP Identifiers??

VM>> IMO, If we have a transport network where LSP can be operated over IP
and Non-IP environments, then Global_ID and ICC should be combined

and called as Operator ID. Can authors of MPLS-TP identifiers draft clarify
this and make necessary changes in the draft?

-- 
Best Regards,
Venkatesan Mahalingam.