Re: [mpls-tp] MPLS-TP identifiers clarification request

[venkatesan mahalingam <[e-mail]>]

Hello TP-Group,
Can transport guys please reply to the below clarification request?

R,
-Venkat.

On Thu, Jun 24, 2010 at 8:20 PM, venkatesan mahalingam <[e-mail]>
wrote:

 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.