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

[venkatesan mahalingam <[e-mail]>]

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.


On Sat, Jun 26, 2010 at 3:55 PM, Huub van Helvoort <[e-mail]>wrote;wrote:

> Hello Vencat,
>
>
> You wrote:
>
>  Hi MPLS-TP group,
>>  Please find below my comments in-line tagged VM>> on MPLS-TP identifiers.
>>
>
> My response [hvh]
>
>
> 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?
>>
>
> [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.
>> 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.
>>
>
> [hvh] no need to remove.
>
>
> 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.
>>
>
> [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.
>
>
> 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?
>>
>
> [hvh] ICC is Global ID.
>
> Best regards, Huub.
>
>
> --
> ================================================================
> Always remember that you are unique...just like everyone else...
>



-- 
Best Regards,
Venkatesan Mahalingam.