Subject: Re: [mpls-tp] [mpls] I-D Action:draft-ietf-mpls-tp-identifiers-02.txt

From: venkatesan mahalingam <[email-masked]>
Date: Tue, 3 Aug 2010 20:59:51 +0530

Hi,
 >> 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.
>We should discuss this (and the above if you like) in Maastricht.
<VM> What was the conclusion made in the IETF-78 on the "two LSP_Nums"
required for bi-directional tunnel?

Thanks,
Venkat.
On Tue, Jul 13, 2010 at 9:12 PM, venkatesan mahalingam <[email-masked]
> wrote:

>  George,
>
> Please find the comments inlined <VM> on this MPLS_TP identifiers draft,
>
> Section 5.1.  MPLS-TP Point to Point Tunnel Identifiers
> It is RECOMMENDED that the IF_Num be auto-generated by adding
>    2^31 to the local Tunnel_Num
>
> <VM> What was the intention to auto-generate IF_Num by adding 2^31 to the
> local Tunnel_Num?
>
> 7.2.2.2.  MEP_IDs for Pseudowires
>  where the Node_ID is the node in which the MEP is located and
>    Tunnel_Num is the tunnel number unique to that node.
> <VM> Typo error, please correct it.
>
>  6.  Pseudowire Path Identifiers
>
>       AGI:Src-Global_ID::Src-Node_ID::Src-AC_ID::Dst-Global_ID::
>       Dst-Node_ID::Dst-AC_ID
> <VM> Does FEC 129 AII Type 2 configuration applicable for both manual and
> signalling PWs?
>      How to represent this AC_ID in the PW mibs? Will there be any
> augmentation in the PW AC mibs (PW-ENET-STD-MIB)?
>
> GS: In Stockholm I was convinced that for ICC based identifiers, only the
> MEG-ID and/or ME-ID would need to be configured at various points along an
> LSP.  Much has changed on this project since then.  Is what we have not
> sufficient?
>
> <VM>  What I infer from your response is, ICC based identifiers are
> applicable only for the MEG-ID and/or ME-ID identification. So, does it mean
> that ICC based operator environment also, MPLS-TP LSP will be created using
> Global_ID? If the answer is yes, i.e Global_Id and ICC should co-exist for
> creating/monitoring the MPLS-TP tunnel, in that case can't we completely
> eliminate the need of ICC based identifier and Global_ID identifier can
> alone be used for creating/monitoring the MPLS-TP tunnel?
>
>  7.1.2.1.  MPLS-TP LSP MEG_IDs
>  Since a MEG pertains to a single MPLS-TP LSP, IP compatible MEG_IDs
>    for MPLS-TP LSPs are simply the corresponding LSP_IDs
>
> <VM> For uni-directional/bi-directional tunnel, one MEG is associated with
> only one LSP (ME).
> For P2MP unidirectional tunnel, one MEG is associated with multiple
> destination LSPs (MEs)
> Is this understanding correct?
>
> <VM> How to configure multiple client MEGs in a server MEG? I believe, we
> don't follow the ITU-T Y1731 MEG level concept in MPLS-TP. Please give us
> some insight into the client MEG and server MEG handling for MPLS-TP.
>
>  >> 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.
>
> >We should discuss this (and the above if you like) in Maastricht.
>
> <VM> I agree with Mach Chen for two LSP_Nums for associated bi-directional
> tunnel,
>
> For example, consider the below topology,
>
> All routers are in different Global_ID operators domain.
>
>   R1-----R2---------R3
>   |                       |
>   |______R4_____|
>
> Tunnel LSP identifier:
> Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::Dst-Tunnel_Num::LSP_Num
>
> Co-routed bi-directional tunnel:
> Co-routed bi-directional tunnel (Tnl_Num=100, LSP_Num=1, Src=R1, Dst=R3) is
> established from R1 to R3 via R2.
> Forward and reverse directions LSP identifier: G1_R1::100::G3_R3::100::1
>
> Associated bi-directional tunnel:
> Associated bi-directional tunnel is established from R1 to R3 via R2 for
> forward direction.
> For this forward direction, LSP identifier is: G1_R1::100::G3_R3::200::*1
> *For reverse direction, a LSP from R3 to R1 via R4 may exist.
> For this reverse direction LSP identifier: G3_R3::200::G1_R1::100::*2
> *
>
> If I assume that the above scenario is valid, we can combine these two
> different LSPs as a single bidirectional LSP only when we have two LSP_Nums.
>
> IMO, two LSP_Nums are required to identify the reverse direction tunnel
> from the forward direction tunnel identifiers and vice versa.
>
> If we want to combine them as single LSP identifier, the LSP identifier
> should be as follows.
>
> Tunnel LSP identifier:
> Src-Global_Node_ID::Src-Tunnel_Num::Src-LSP_Num::Dst-Global_Node_ID::Dst-Tunnel_Num::Dst-LSP_Num
>
> Example: G1_R1::100::*1*::G3_R3::200::*2*
>
> Please correct me if I'm wrong in the understanding.
>
> BR,
>
> Venkat.
>
> On Tue, Jul 13, 2010 at 5:00 AM, <[email-masked]> wrote:
>
>>  A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Multiprotocol Label Switching Working
>> Group of the IETF.
>>
>>
>>        Title           : MPLS-TP Identifiers
>>        Author(s)       : M. Bocci, G. Swallow
>>        Filename        : draft-ietf-mpls-tp-identifiers-02.txt
>>        Pages           : 14
>>        Date            : 2010-07-12
>>
>> This document specifies identifiers for MPLS-TP objects.  Included
>> are identifiers conformant to existing ITU conventions and
>> identifiers which are compatible with existing IP, MPLS, GMPLS, and
>> Pseudowire definitions.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-identifiers-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>
>
> --
> Best Regards,
> Venkatesan Mahalingam.
>

-- 
Best Regards,
Venkatesan Mahalingam.