Subject: Re: [mpls-tp] MPLS-TP tunnel and PW establishment over multiple different operators

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 1 Jul 2010 13:24:07 +0530

Hi,

I guess transport people will be able to provide more pointers and
suggestions against such deployment possibilities for MPLS_TP.
Is this not a valid scenario that needs to be discussed?

Thanks,
Venkat.

On 6/30/10, venkatesan mahalingam <[email-masked]> wrote:
> Hi,
> Can transport guys please reply to the below query?
>
> Thanks,
> Venkat.
>
> On 6/30/10, venkatesan mahalingam <[email-masked]> wrote:
>> Hi,
>> Can we establish a LSP/PW between MPLS-TP operators with different
>> identifiers (ICC and Global_ID)?
>>
>> for example,
>>
>> Operator1 ----------Operator2----------------Operator3----------------Operator-4
>>  (ICC)                    (ICC)                    (Global_ID)              (Global_ID)
>>
>> Can single LSP/PW be traversed between Operator1 and Operator-4?
>> If the answer is NO, do we need to maintain two LSPs/PWs, one between
>> Operator1 and Operator2 and
>> another one between Operator3 and Operator4 and LSP/PW stitching with
>> these
>> two LSPs/PWs for communication across operators?
>>
>>
>> Thanks,
>> Venkat.
>>
>> On Mon, Jun 28, 2010 at 11:13 PM, venkatesan mahalingam <
>> [email-masked]> wrote:
>>
>>> Hi,
>>>
>>> Please clarify whether the below operations are valid for MPLS-TP
>>> deployment.
>>>
>>> For example,
>>> *Scenario-1:*
>>> Operator1 -------------------Operator2--------------------Operator3
>>>  (ICC - IP capable)    (ICC- IP capable)        (ICC IP incapable)
>>>
>>>  Can single LSP/PW be established over ICC based operators in an IP and
>>> Non-IP environments?
>>>  **
>>> *Scenario-2:*
>>> Operator1 -----------------Operator2--------------Operator3-------------Operator-4
>>>  (ICC - IP capable)   (ICC- IP capable)   (ICC IP incapable)      (ICC IP incapable)
>>>
>>> Can single LSP/PW be established between Operator1 and Opearator-4?
>>> If the answer is NO, do we need to maintain two LSPs/PWs, one between
>>> Operator1 and Operator2 and
>>> another one between Operator3 and Operator4 and LSP/PW stitching with
>>> these
>>> two LSPs/PWs?
>>>
>>>  *Scenario-3:*
>>> Operator1
>>> ---------------------------Operator2--------------------------------Operator3
>>> (Global_ID - IP capable)    (Global_ID - IP capable)        (Global_ID
>>> IP
>>> incapable)
>>>
>>>  Can single LSP/PW be established over Global_ID based operators in an
>>> IP
>>> and Non-IP environments?
>>>  **
>>> *Scenario-4:*
>>> Operator1
>>> -----------------------------Operator2------------------------Operator3------------------------------Operator-4
>>>  (Global_ID - IP capable)    (Global_ID- IP capable)        (Global_ID
>>> IP
>>> incapable)       (Global_ID IP incapable)
>>>
>>> Can single LSP/PW be established between Operator1 and Opearator-4?
>>> If the answer is NO, do we need to maintain two LSPs/PWs, one between
>>> Operator1 and Operator2 and
>>> another one between Operator3 and Operator4 and LSP/PW stitching with
>>> these
>>> two LSPs/PWs?
>>>
>>> *Scenario-5:*
>>>  Operator1
>>> --------------------------------Operator2--------------------Operator3
>>>  (Global_ID- IP capable)         (ICC- IP capable)        (Global_ID IP
>>> capable)
>>>
>>>  Can single LSP/PW be established over different operators in an IP
>>> environments?
>>>  **
>>>  *Scenario-6:*
>>>  Operator1
>>> -----------------------------Operator2--------------------Operator3
>>>  (ICC- IP incapable)         (Global- IP incapable)        (ICC IP
>>> incapable)
>>>
>>>  Can single LSP/PW be established over different operators in an Non-IP
>>> environments?
>>>
>>> *Scenario-7:*
>>> Operator1
>>> -------------------Operator2--------------------Operator3---------------------------Operator-4
>>>  (ICC - IP capable)    (ICC- IP capable)        (Global_ID IP
>>> capable)            (Global_ID IP capable)
>>>
>>> Can single LSP/PW be established between Operator1 and Opearator-4?
>>> If the answer is NO, do we need to maintain two LSPs/PWs, one between
>>> Operator1 and Operator2 and
>>> another one between Operator3 and Operator4 and LSP/PW stitching with
>>> these
>>> two LSPs/PWs?
>>>
>>>  *Scenario-8:*
>>> Operator1
>>> -------------------Operator2--------------------Operator3---------------------------Operator-4
>>>  (ICC - IP capable)    (ICC- IP capable)        (Global_ID IP
>>> incapable)          (Global_ID IP incapable)
>>>
>>> Can single LSP/PW be established between Operator1 and Opearator-4?
>>> If the answer is NO, do we need to maintain two LSPs/PWs, one between
>>> Operator1 and Operator2 and
>>> another one between Operator3 and Operator4 and LSP/PW stitching with
>>> these
>>> two LSPs/PWs?
>>>
>>>  *Scenario-9:*
>>> Operator1
>>> -------------------Operator2-----------------------------Operator3---------------------------Operator-4
>>>  (ICC - IP capable)    (Global_ID- IP capable)        (ICC IP
>>> incapable)          (Global_ID IP incapable)
>>>
>>> Can single LSP/PW be established between Operator1 and Opearator-4?
>>> If the answer is NO, do we need to maintain two LSPs/PWs, one between
>>> Operator1 and Operator2 and
>>> another one between Operator3 and Operator4 and LSP/PW stitching with
>>> these
>>> two LSPs/PWs?
>>>
>>>  *Scenario-9:*
>>> Operator1
>>> -------------------------Operator2------------------------Operator3---------------------------Operator-4
>>>  (ICC - IP capable)    (Global_ID- IP incapable)        (Global_ID IP
>>> capable)          (ICC IP incapable)
>>>
>>> Can single LSP/PW be established between Operator1 and Opearator-4?
>>> Is this a valid scenario?
>>>
>>> --
>>> Best Regards,
>>> Venkatesan Mahalingam.
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Venkatesan Mahalingam.
>>
>
>
> --
> Best Regards,
> Venkatesan Mahalingam.
>

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: <[email-masked]>
Date: Thu, 1 Jul 2010 09:22:18 +0100

Here is my view of some of the issues that should be
understood/considered here:

-	the most important use-case of a transport network is creating
client layer network topology.  Now the client can also be the same
technology as the server...and here being able to provide
MPLS-TPoverMPLS-TP as a proper client/server relationship will be key to
the success of MPLS-TP as a transport network.  In a client/server
relationship the DP/CP/MP of the client and server layer networks are
fully functionally isolated/independent...so the issue you raise below
(and which only considers DP addressing mismatching) is a non-issue ina
proper client/server case.

-	you are showing a E-NNI relationship, ie a single layer network
that is peered between 2 different parties.  This implies a horizontal
partitioning of a single layer network....and so we have to consider the
interoperability of *all* the DP/CP/MP components, ie it is more than
simple DP access point addressing.  Note carefully that when components
are not idetical then we have a protocol/function converison problem to
deal with...this case may have no solution at all if the 2 technolgies
do not belong to same network mode (eg one is cl-ps and the other co-ps
or co-cs) and there is oftem significant misalignment when the 2
technologies belong to the same mode.

-	also note carefully that when peer interworking we do not nor
normally peer the MP, and we restrict the scope of the CP signalling and
routing components....in other words an E-NNI between nodes belonging to
different parties is very different to an I-NNI between nodes belonging
to the same party.

-	all the above is all academic in any case for MPLS-TP as we
should never peer network technologies that are not TOS
(Top-Of-Stack)....most technologies are NOT TOS.  A TOS network directly
supports external message/file/stream applications via key application
adaptation functions....very few network technologies have these, eg IP
has (UDP/TCP/RTP), ATM has (AALs) and the PSTN has (eg various voice
(stream) encoding schemes such as A/u-law PCM sampling quantizing).  A
TOS layer network exists in *all* networking scenarios...if it does not
then all lower layer networking serves no purpose at all.  By definition
a non-TOS network MUST carry a TOS layer network.  It therefore
immediately follows that there is no point whatsoever in peer
interworking a non-TOS layer network across an E-NNI, we should simply
fully terminate the DP/CP/MP of the non-TOS layer network at the
interworking point and pass across the higher layer TOS layer network
transparently.

Aside=> One see this error of pushing unnecessary E-NNIs in all sorts of
technology promoting fora...I suppose its politically/commercailly
understandable ('rule the world' minset), even if obviously technically
unnecessary wrt the work and costs/problems it creates.

Hope that helps.

regards, Neil. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of venkatesan mahalingam
> Sent: 01 July 2010 08:54
> To: [email-masked]
> Subject: Re: [mpls-tp] MPLS-TP tunnel and PW establishment 
> over multipledifferent operators
> 
> Hi,
> 
> I guess transport people will be able to provide more 
> pointers and suggestions against such deployment 
> possibilities for MPLS_TP.
> ----------Operator2----------------Operator3----------------Operator-4
> >>  (ICC)                    (ICC)                    
> (Global_ID)              (Global_ID)
> >>
> >> these two LSPs/PWs for communication across operators?
> >>
> >>
> >> Thanks,
> >> Venkat.
> >>
> -------------------Operator2--------------------Operator3
> >>>  Can single LSP/PW be established over ICC based 
> operators in an IP 
> >>> and Non-IP environments?
> >>>  **
> >>> *Scenario-2:*
> >>> Operator1 
> -----------------Operator2--------------Operator3-------------
> Operator-4
> >>> another one between Operator3 and Operator4 and LSP/PW stitching 
> >>> with these two LSPs/PWs?
> >>>
> >>>  *Scenario-3:*
> >>> Operator1
> >>> 
> >>>  Can single LSP/PW be established over Global_ID based 
> operators in 
> >>> an IP and Non-IP environments?
> >>>  **
> >>> *Scenario-4:*
> >>> Operator1
> >>> 
> -----------------------------Operator2------------------------
> Operator3------------------------------Operator-4
> >>> another one between Operator3 and Operator4 and LSP/PW stitching 
> >>> with these two LSPs/PWs?
> >>>
> >>> *Scenario-5:*
> >>>  Operator1
> >>> 
> >>>  Can single LSP/PW be established over different operators in an 
> >>> Non-IP environments?
> >>>
> >>> *Scenario-7:*
> >>> Operator1
> >>> 
> >>> another one between Operator3 and Operator4 and LSP/PW stitching 
> >>> with these two LSPs/PWs?
> >>>
> >>>  *Scenario-8:*
> >>> Operator1
> >>> 
> >>> another one between Operator3 and Operator4 and LSP/PW stitching 
> >>> with these two LSPs/PWs?
> >>>
> >>>  *Scenario-9:*
> >>> Operator1
> >>> 
> -------------------Operator2-----------------------------Opera
> tor3---------------------------Operator-4
> >>> another one between Operator3 and Operator4 and LSP/PW stitching 
> >>> with these two LSPs/PWs?
> >>>
> >>>  *Scenario-9:*
> >>> Operator1
> >>> 
> -------------------------Operator2------------------------Oper
> ator3---------------------------Operator-4
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>