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

From: David Ward <[email-masked]>
Date: Fri, 4 Apr 2008 08:27:53 -0500

Begin forwarded message:

> From: Maarten Vissers <[email-masked]>
> Date: April 4, 2008 6:27:11 AM CDT
> To: David Ward <[email-masked]>, Malcolm Betts  
> <[email-masked]>, Huub van Helvoort <[email-masked]>
> 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: "BOCCI Matthew" <[email-masked]>
Date: Fri, 4 Apr 2008 15:37:58 +0200

Dave,
 
Thanks for forwarding this.
 
Maarten's email suggests a PW in PW model for carriers carrier PWE3
services. This has not been defined yet, but there has been some
discussion in the PWE3 WG as to whether we need a "generic" or "MPLS" or
"PW" PW-type to handle this.
 
Matthew

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Ward
	Sent: 04 April 2008 14:28
	To: [email-masked]
	Subject: [Mpls-interop] Fwd: (t)mpls oam frame

	Begin forwarded message:

		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.

		Regards,
		Maarten

---

From: George Swallow <[email-masked]>
Date: Fri, 04 Apr 2008 10:40:10 -0400

> "PW" PW-type to handle this.

It wasn't clear to me whether Maarten was suggesting that the PW in PW
was part of the problem or part of the solution.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: "LASSERRE, Marc \(Marc\)" <[email-masked]>
Date: Fri, 4 Apr 2008 17:04:16 +0200

I do not understand why this would prevent further label stacking from
being done.

In the example below, carrier A traffic is carried of carried B (MPLS
over PW). Carrier B traffic could also be carried in the same way over
carrier C.

As far as OAM is concerned, each layer is independent (i.e. would look
at its own ACH) - the rest is considered payload.

Marc

Sent: vendredi 4 avril 2008 15:28

Begin forwarded message:

To: David Ward <[email-masked]>, Malcolm Betts <[email-masked]>,
Huub van Helvoort <[email-masked]>

Dave, Malcolm, Huub,

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.

service).

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

| Carrier B PW Label     |

| Carrier A PW Label     |

|          ...           |

|                        |

|                        |

Regards,

Maarten

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 4 Apr 2008 08:37:36 -0700

I think Maarten is considering it to be the solution, but I don't think
it is necessarily the correct one.  There are a number of inter-AS LSP
options that don't require multiple label stacks. 

>-----Original Message-----
>From: George Swallow [mailto:[email-masked]] 
>Sent: Friday, April 04, 2008 7:40 AM
>To: BOCCI Matthew
>Cc: [email-masked]
>Subject: Re: [Mpls-interop] Fwd: (t)mpls oam frame
>
>> discussion in the PWE3 WG as to whether we need a "generic" 
>or "MPLS" 
>> or "PW" PW-type to handle this.
>
>It wasn't clear to me whether Maarten was suggesting that the 
>PW in PW was part of the problem or part of the solution.
>
>...George
>

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 4 Apr 2008 13:20:12 -0500

Agree, I think Maarten is wary the only solution for carrier's carrier
is PW over PW. In G8110.1 Amd 1, in Appendix IV (Fig 12-16), they
provide an example of carrier's carrier (with Maarten's terminology
defined of TMC/TMP) and a solution using label stacking of ITU's
proposed TMPLS OAM PDU. They treat the TMPLS layer network as "one"
layer from UNI to UNI (over multiple administrative domains) and use a
combination of MEG levels and label stacking for OAM.

http://ties.itu.int/ftp/public/itu-t/ahtmpls/readandwrite/doc_exchange/g
eneral-documents/T-REC-G.8110.1-200707-P!Amd1!PDF-E.pdf 

My question would be to ask ITU if there is a TMPLS OAM requirement
which requires (only) one-layer across multiple administrative domains?
Or can a client/server relationship of TMPLS/TMPLS be used for
networking across multiple domains? As John notes, there are already
multiple solution options defined, we just need to understand the basis
of the requirements (vs. e.g. Appendix IV's solution).

Deborah

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Drake, John E
Sent: Friday, April 04, 2008 11:38 AM
To: George Swallow; BOCCI Matthew
Cc: [email-masked]
Subject: Re: [Mpls-interop] Fwd: (t)mpls oam frame

---

From: David Ward <[email-masked]>
Date: Sat, 5 Apr 2008 17:05:31 -0500

Deborah -

I think the best way to accomplish this is to restate what you wrote  
into a question to the ad hoc team, dt, JWT all at the same time. We  
should be able to point to a CC solution in the slidedeck as an  
example of solving the problem, reference to ITU docs ...

Note that I don't understand why there would be a technical  
requirement for only one-layer across admin domains. The service can  
be provide, OAM can be maintained at all layers, ... it works. But, I  
may be missing something simple. Would you be willing to recraft your  
email into a question to the larger group?

Thanks

-DWard

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 7 Apr 2008 16:35:54 -0500

Hi Dave,

I'm not sure what Maarten's concerns are anymore after reading Malcolm's
followup mails with him. And the new slide deck clarifies that the ACH
can be associated with an LSP (not only PW) which I was thinking might
have been some of the confusion with the previous deck.

I think best is to wait and see if he has more comments on this version.

Deborah

-----Original Message-----
From: David Ward [mailto:[email-masked]] 
Sent: Saturday, April 05, 2008 6:06 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: David Ward; Drake, John E; George Swallow; BOCCI Matthew;
[email-masked]

Deborah -

Thanks

-DWard