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

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 24 Jun 2010 20:20:02 +0530

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.

---

From: venkatesan mahalingam <[email-masked]>
Date: Sat, 26 Jun 2010 01:16:59 +0530

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 <[email-masked]>
wrote:

 Hi MPLS-TP group,

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

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?

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

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.

---

From: Huub van Helvoort <[email-masked]>
Date: Sat, 26 Jun 2010 12:25:27 +0200

Hello Vencat,

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

My response [hvh]

>  >>This seems to define a bidirectional tunnel. Is that the intent? If
> so please clarify. If not then why
> the reverse direction would do better as you would have a return path
> for OAM and DCC etc.
> *

[hvh] consider uni-directional as a special, or initial case of
unidirectional p-2-mp. So IMHO the answer is: yes, we need uni-dir.

> If the answer yes, then do we need to remove the below requirements of
> an MPLS-TP from the RFC-5654.

[hvh] no need to remove.

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

[hvh] in transport forward and reverse co-routed LSPs are switched
simultaneous.

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

[hvh] we need a single LSP_Num for unidirectional LSP, one LSP_Nums
for forward and reverse direction co-routed, and two LSP nums for
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?

[hvh] no, it is important for co-routed that exactly the same
path is setup, it will be difficult to achieve when first the
forward path is setup and then the reverse path.

>  >All the sections on identifiers further in the draft, mention the
> globally unique format of the identifiers by pre-pending the Global_ID.
> 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?

[hvh] ICC is Global ID.

Best regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: venkatesan mahalingam <[email-masked]>
Date: Sat, 26 Jun 2010 17:07:35 +0530

Hello,

Thanks for your response. I have further query on your response [hvh] ICC is
Global ID.

As per BUSI ITALO response *Dated*: Fri, 9 Apr 2010 09:34:28 +0200
 An MPLS-TP enabled switch may be deployed either by a transport operator,
who manages his network according to ITU-T operations, or by an IP operator,
who manages his network according to IP operations.

In the latter case, I understand that the Global_ID is likely to be used to
identify the operator while the ICC will be used in the former case.

If you are building an MPLS-TP switch addressing both types of operators you
need to support both types of operators' identification.

VM>> There is a need to keep the Global_ID and ICC for MPLS-TP operator
identification.
If you say, ICC is Global_ID, then what I understand is that ICC based
transport operator identification is not required and Global_ID used by an
IP operator alone is sufficient to identify an operator in the MPLS-TP
network.
Is this understanding right?

It seems that the ICC based identifiers [ICC based MEG_IDs, ICC based
MEP_IDs etc..] for MPLS-TP in the draft *draft-ietf-mpls-tp-identifiers-01 *are
incomplete.
When is the next version of this draft with complete information for ICC
based identifiers expected if the ICC is required for MPLS-TP?

If both Global_ID and ICC are required then draft authors can change the
text of this draft as follows to identify the operator.
MPLS-TP operator can be identified using *Operator_ID, Operator_ID
*implies Global_ID
or ICC_ID.

R,
Venkat.

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Huub van Helvoort <[email-masked]>
Date: Sat, 26 Jun 2010 22:49:50 +0200

Hello Venkat,

You replied:

> Thanks for your response. I have further query on your response [hvh]
> ICC is Global ID.
> As per BUSI ITALO response /Dated/: Fri, 9 Apr 2010 09:34:28 +0200
> An MPLS-TP enabled switch may be deployed either by a transport
> operator, who manages his network according to ITU-T operations, or by
> an IP operator, who manages his network according to IP operations.
> In the latter case, I understand that the Global_ID is likely to be used
> to identify the operator while the ICC will be used in the former case.
> If you are building an MPLS-TP switch addressing both types of operators
> you need to support both types of operators' identification.
> transport operator identification is not required and Global_ID used by
> an IP operator alone is sufficient to identify an operator in the
> MPLS-TP network.

[hvh] what I tried to say is that the ICC can also be considered
a Global ID.
However the format of the IP Global ID may be different from the
transport/ICC Global ID.

So both must be supported.

> MEP_IDs etc..] for MPLS-TP in the draft
> *draft-ietf-mpls-tp-identifiers-01 *are incomplete.

[hvh] that is a question for the editors.

> *implies Global_ID or ICC_ID.

[hvh] good proposal.

Cheers, Huub.