Subject: [Mpls-interop] Fwd: (t)mpls oam frame

From: David Ward <[email-masked]>
Date: Fri, 4 Apr 2008 13:22:14 -0500

Begin forwarded message:

> From: Maarten Vissers <[email-masked]>
> Date: April 4, 2008 1:19:46 PM CDT
> To: "'Malcolm Betts'" <[email-masked]>, "'David Ward'"  
> <[email-masked]>, "'Huub van Helvoort'" <[email-masked]>
> Subject: RE: (t)mpls oam frame
>
> Malcolm,
>
> Slide 24 in the MPLS-TP_overview-09-betts.ppt file shows a PWL/BOS  
> field
> followed by either a CW or PWE-3 ACH field. I was told and  
> understand this
> as a PW Label with Bottom of Stack bit set, which is immediately  
> followed by
> the ACH field (i.e. without LFU/BOS label with OAM label value).  
> This is
> also what I see in slide 33 where for PW OAM the yellow PW label is  
> followed
> by a red ACH field (or the white CW field).
>
> In figure 24 of C610
> http://ties.itu.int/u/tsg15/sg15/documents/c/T05-SG15-C-0610!!MSW- 
> E.doc I
> have described a carrier-carrier application in which a carrier- 
> carrier
> network provides connectivity for T-MPLS Path connections (i.e.  
> tunnels)
> between carrier A and carrier B networks via its T-MPLS Channel  
> (i.e. PW)
> layer. This application will be present also when a carrier A needs to
> connect to its NTU or MTU device located at a customer premise via  
> a third
> party regional carrier B (e.g. BT needs to connect to a customer in  
> the
> netherlands via the KPN network). This is depicted in figure 26 of  
> C610.
> This latter case also supports in a very straightforward manner the  
> service
> management requirements as per G.8601.
>
> What you now get is that the PW layer in the carrier-carrier or the
> regional-carrier networks will be required to have the CW between the
> carrier's tunnel label and the carrier-carrier/regional-carrier's  
> PW label.
> If this is not appreciated, and instead you would like to see the  
> carrier's
> tunnel label directly above the carrier-carrier/regional-carrier's  
> PW label
> (i.e. without intermediate CW field), then you may want to have the  
> LFU/BOS
> label also in the PW OAM case.
>
> Regards,
> Maarten
>
> -----Original Message-----
> From: Malcolm Betts [mailto:[email-masked]]
> Sent: 04 April 2008 16:14
> To: Maarten Vissers; David Ward; Huub van Helvoort
> Subject: RE: (t)mpls oam frame
>
> Maarten, I am not following your argument.
>
> The current assumption is that when a MEP is present a new label is  
> added to
> the stack.  So all client traffic now has this new tunnel label.   
> When an
> OAM frame is inserted into to stream it has the OAM pdu
> + ACH + OAM alert label + tunnel label.  A frame is only directed to a
> sink MEP if the OAM alert label is at the top of the stack.
>
> So the frames on the wire are:
>
> client payload
> Label
>   :
>   :
> Tunnel label
>
> or for OAM:
>
> carrier 1 OAM pdu
> ACH
> OAM alert
> tunnel label
>
> If that carrier 1 frame to a transit carrier then the carrier 1  
> (end to
> end) OAM is encapsulated the same as the payload and the OAM alert  
> label
> (for carrier 1 OAM) is not visible to the carrier 2 MEP.
>
> The current proposal to reach a MIP is to set the ttl of the tunnel  
> label
> such that it expires at the MIP and therefore the OAM alert label is
> "exposed" and the ACH and pdu are directed to the MIP.
>
>
>
> Malcolm Betts
> Nortel Networks
> Phone: +1 613 763 7860 (ESN 393)
> email: [email-masked]
>
> Confidentiality Notice:  This message and any attachments may contain
> information that is privileged and confidential. If you have reason to
> believe that you are not the intended recipient or a person  
> responsible for
> delivering this message to an intended recipient, you are hereby  
> notified
> that any review, dissemination, distribution, or copying of this  
> message is
> strictly prohibited. If you have reason to believe that you are not  
> the
> intended recipient or a person responsible for delivering this  
> message to an
> intended recipient, please contact the sender immediately by reply  
> email and
> destroy all copies of the original message.
>
>
>> -----Original Message-----
>> From: Maarten Vissers [mailto:[email-masked]]
>> Sent: Friday, April 04, 2008 7:27 AM
>> To: David Ward; Betts, Malcolm (CAR:X632); Huub van Helvoort
>> Subject: (t)mpls oam frame
>>
>> Dave, Malcolm, Huub,
>>
>> I have heard that you consider the use of the ACH to identify T-MPLS
>> Channel/MPLS PW OAM. If we do this, then we create a situation  
>> that is
>> compatible with ATM. In ATM the VP OAM is identified by a reserved  
>> VCI
>> (i.e.
>> label) an the VC OAM is identified by a Payload Type ID.
>>
>> I don't know if you have considered the implication of such choice
>> with respect to the carrier-carrier application that we intent to
>> support in T-MPLS networks and which application I believe is also on
>> the agenda of MPLS networks.
>>
>> In such carrier-carrier application we will see that the Tunnel (TMP
>> connection) of Carrier A is treated as a customer service instance by
>> Carrier B. Carrier B will support this service via a PW (TMC
>> connection).
>> Such service may be provided as an individual Tunnel service, or as a
>> Tunnel-bundle service (i.e. multiple Tunnels are treated as a single
>> service).
>>
>> In both cases (individual, bundle) the choice of the ACH header in
>> PW/TMC OAM requires that any client signal (including the Tunnel's of
>> Carrier A) are encapsulated with a Control Word. For the bundle case
>> this implies that the Tunnel label (of Carrier A's tunnels) is
>> preceeded by a Control Word (of Carrier B's encapsulation). It will
>> thus not be possible to continue the label stack in a Carrier-Carrier
>> application.
>>
>> --------------------------
>> | Carrier B Tunnel Label |
>> --------------------------
>> | Carrier B PW Label     |
>> --------------------------
>> | Carrier B Control Word |
>> --------------------------
>> | Carrier A Tunnel Label |
>> --------------------------
>> | Carrier A PW Label     |
>> --------------------------
>> |          ...           |
>> |                        |
>> |                        |
>> --------------------------
>>
>> Regards,
>> Maarten
>>
>>
>>
>
>

_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Luca Martini <[email-masked]>
Date: Fri, 04 Apr 2008 13:08:04 -0600

It seems to me that the requirement is really for stacked OAM flows.
The data plane is still form PE in carrier A to PE in Carrier B.  The 
issue here is that carrier B needs to allow carrier A to send OAM to 
it's MTU, or NTU.
I do not believe that this equates  into a PW in PW scenario.

Luca

David Ward wrote:
>
>
> Begin forwarded message:
>> *From: *Maarten Vissers <[email-masked] 
>> <mailto:[email-masked]>>
>> *Date: *April 4, 2008 1:19:46 PM CDT
>> *To: *"'Malcolm Betts'" <[email-masked] 
>> <mailto:[email-masked]>>, "'David Ward'" <[email-masked] 
>> <mailto:[email-masked]>>, "'Huub van Helvoort'" 
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject: **RE: (t)mpls oam frame*
>>
>> Malcolm,
>>
>> Slide 24 in the MPLS-TP_overview-09-betts.ppt file shows a PWL/BOS field
>> followed by either a CW or PWE-3 ACH field. I was told and understand 
>> this
>> the ACH field (i.e. without LFU/BOS label with OAM label value). This is
>> http://ties.itu.int/u/tsg15/sg15/documents/c/T05-SG15-C-0610!!MSW-E.doc 
>> <http://ties.itu.int/u/tsg15/sg15/documents/c/T05-SG15-C-0610%21%21MSW-E.doc> 
>> I
>> have described a carrier-carrier application in which a carrier-carrier
>> network provides connectivity for T-MPLS Path connections (i.e. tunnels)
>> between carrier A and carrier B networks via its T-MPLS Channel (i.e. PW)
>> connect to its NTU or MTU device located at a customer premise via a 
>> third
>> party regional carrier B (e.g. BT needs to connect to a customer in the
>> netherlands via the KPN network). This is depicted in figure 26 of C610.
>> carrier's tunnel label and the carrier-carrier/regional-carrier's PW 
>> label.
>> tunnel label directly above the carrier-carrier/regional-carrier's PW 
>> label
>> the stack.  So all client traffic now has this new tunnel label.  When an
>> If that carrier 1 frame to a transit carrier then the carrier 1 (end to
>> end) OAM is encapsulated the same as the payload and the OAM alert label
>> The current proposal to reach a MIP is to set the ttl of the tunnel label
>> email: [email-masked] <mailto:[email-masked]>
>>
>> delivering this message to an intended recipient, you are hereby notified
>> strictly prohibited. If you have reason to believe that you are not the
>>> Channel/MPLS PW OAM. If we do this, then we create a situation that is 
>>> compatible with ATM. In ATM the VP OAM is identified by a reserved VCI 
>>> (i.e.
> ------------------------------------------------------------------------
>

---

From: David Ward <[email-masked]>
Date: Fri, 4 Apr 2008 15:48:33 -0500

Either way, an example of Carriers-carrier seems warranted. Can the  
folks on the forwarding and oam subteams hack up a lblstack scenario  
and one w/ an e2e PW?

Thanks

-DWard

On Apr 4, 2008, at 2:08 PM, Luca Martini wrote:

> The data plane is still form PE in carrier A to PE in Carrier B.   
> The issue here is that carrier B needs to allow carrier A to send  
> OAM to it's MTU, or NTU.
>>> also what I see in slide 33 where for PW OAM the yellow PW label  
>>> is followed
>>> E.doc <http://ties.itu.int/u/tsg15/sg15/documents/c/T05-SG15- 
>>> C-0610%21%21MSW-E.doc> I
>>> connect to its NTU or MTU device located at a customer premise  
>>> via a third
>>> This latter case also supports in a very straightforward manner  
>>> the service
>>> tunnel label directly above the carrier-carrier/regional- 
>>> carrier's PW label
>>> (i.e. without intermediate CW field), then you may want to have  
>>> the LFU/BOS
>>> From: Malcolm Betts [mailto:[email-masked]] Sent: 04 April  
>>> 2008 16:14
>>> The current assumption is that when a MEP is present a new label  
>>> is added to
>>> intended recipient, please contact the sender immediately by  
>>> reply email and
>>>> I have heard that you consider the use of the ACH to identify T- 
>>>> MPLS Channel/MPLS PW OAM. If we do this, then we create a  
>>>> situation that is compatible with ATM. In ATM the VP OAM is  
>>>> identified by a reserved VCI (i.e.
>>>> I don't know if you have considered the implication of such  
>>>> choice with respect to the carrier-carrier application that we  
>>>> intent to support in T-MPLS networks and which application I  
>>>> believe is also on the agenda of MPLS networks.
>>>>
>>>> connection) of Carrier A is treated as a customer service  
>>>> instance by Carrier B. Carrier B will support this service via a  
>>>> PW (TMC connection).
>>>> Such service may be provided as an individual Tunnel service, or  
>>>> as a Tunnel-bundle service (i.e. multiple Tunnels are treated as  
>>>> a single service).
>>>>
>>>> In both cases (individual, bundle) the choice of the ACH header  
>>>> in PW/TMC OAM requires that any client signal (including the  
>>>> Tunnel's of Carrier A) are encapsulated with a Control Word. For  
>>>> the bundle case this implies that the Tunnel label (of Carrier  
>>>> A's tunnels) is preceeded by a Control Word (of Carrier B's  
>>>> encapsulation). It will thus not be possible to continue the  
>>>> label stack in a Carrier-Carrier application.
>>>>

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 4 Apr 2008 19:14:35 -0400

i was thinking he same thing earlier.

Sent from my hacked and unlocked iPhone!

On Apr 4, 2008, at 3:08 PM, Luca Martini <[email-masked]> wrote:

>>> understand
>>> <http://ties.itu.int/u/tsg15/sg15/documents/c/T05-SG15-C-0610%21%21MSW-E.doc 
>>> >
>>> I
>>> PW
>>>> MPLS
>>>> instance by
>>>> as a
>> --- 
>> ---------------------------------------------------------------------
>>