Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 16 Jul 2003 04:42:49 -0400

George,
I just send an updated slide set to Danny for my presentation this
afternoon of draft-aissaoui-extended-pid. I added an example
application where the translation of PID between FR, PW, and
Ethernet is very useful. The main point is that in many of the
installed base of L2 VPN, FR and ATM VCs carry more than one user
payload (e.g., IP and IS-IS/CLNP). In those cases only, a
translation of PID is useful if one one wants to have dissimilar L2
access over a PW (e.g., FR-MPLS-Ethernet). 

I hope Danny will upload it soon so that everone will have a chance
to see it before the meeting this afternoon.

Mustapha.
----------
George Swallow wrote:
> 
> > 5.4.4. MPLS Payload Identifier
> >
> >
> >     If technical considerations result in a PW control word that may
> >     alias an IP packet, the control word SHOULD be preceded by an MPLS
> >     payload type identifier.
> >
> 
> What problem does this solve that just adding four bytes to your
> header (in the putative case) doesn't solve?
> 
> ...George
> 
> ========================================================================
> George Swallow             Cisco Systems                  (978) 936-1398
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719

---

From: Luca Martini <[email-masked]>
Date: Wed, 16 Jul 2003 05:14:54 -0600

and what does this add that cannot be indicated by an MPLS label ?

Luca

Mustapha Aissaoui wrote:
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 16 Jul 2003 08:05:26 -0400

Luca,
a MPLS label cannot indicate that both IP and IS-IS/CLNP are being
carried in the PW. You would need either to extend FR (or Ethernet)
to the remote PE or create multiple PWs for each payload in the
terminated FR VC. 
The first solution is valid but the issue is that you typically do
not expect all remote PE's (which have only GigE and MPLS
interfaces) to understand FRoMPLS and RFC 2427. The multiple PWs per
FR VC is not practical. So, the translation of the FR and Ethernet
PIDs to the PW PID allows a suitable solution.  

Mustapha.
---------------

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 16 Jul 2003 08:23:06 -0400

> I just send an updated slide set to Danny for my presentation 
> this afternoon of draft-aissaoui-extended-pid. I added an 
> example application where the translation of PID between FR, 
> PW, and Ethernet is very useful. The main point is that in 
> many of the installed base of L2 VPN, FR and ATM VCs carry 
> more than one user payload (e.g., IP and IS-IS/CLNP). In 
> those cases only, a translation of PID is useful if one one 
> wants to have dissimilar L2 access over a PW (e.g., 
> FR-MPLS-Ethernet). 

	I thought that interworking was out of the scope
in PWE3?

	--Tom

> 
> I hope Danny will upload it soon so that everone will have a 
> chance to see it before the meeting this afternoon.
> 
> Mustapha.
> ----------
> George Swallow wrote:
> >

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 16 Jul 2003 08:26:13 -0400

One other point. It seems to me that
an MPLS label can be used to indicate the
VC and its type, since the PE would have
had to signal the VC originally.  It 
doesn't seem to me that this added overhead
is useful.

	--Tom

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mustapha Aissaoui
> Sent: Wednesday, July 16, 2003 4:43 AM
> To: George Swallow
> Cc: [email-masked]; [email-masked]
> Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4
> 
> 
> George,

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 16 Jul 2003 09:50:32 -0400

There was a good show of hands
(fronts only) in favor of support to adopt 
the draft-nadeau-pwe3-vccv-01.txt as a
PWE3 working group document, and none
against. The chairs asked that we "take 
it to the list" to confirm.

	--Tom

---

From: Luca Martini <[email-masked]>
Date: Thu, 17 Jul 2003 05:38:29 -0600

Mustapha,

my statement is simple:

PW PID == an MPLS label + control plane assignment.

In the end there is very little difference in assigning another label in the 
form of a pw PID , or in the form of an MPLS label to the packet.
Why would one build specialized hardware to support a minority of protocols , 
when we can all lump it into MPLS and using current forwarding hardware.

Luca

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 17 Jul 2003 08:06:12 -0400

Luca,
you are still talking about option 2, which is assigning a label for
each user protocol. This means the PE will need to break each FR VC
into a multitude of PWs (1-to-N) and signal the association to the
remote PE. In my view, this is much more complex than a simple PID
translation.

As for the specialized hardware, a device which manipulates the
MPLS/PW PID for the LSP-Ping/VCCV will be capable of doing a
straighforward tranlsation towards Ethernet or FR PID.

As I said in my presentation, this draft is not intended to replace
the existing MPLS/PW forwarding paradigm. Is should only be used in
cases where needed, like the OAM.

Mustapha.
---------

---

From: Wei Luo <[email-masked]>
Date: Thu, 17 Jul 2003 11:13:57 -0700

First of all, what is the need to demultiplex different protocols carried in one
DLCI to different PWs?  Is it because you want to send them to different
destinations?  Not sure if the current FR switches (PEs) for legacy L2VPNs can
demultiplex packets from a single DLCI into different PVCs.

Suppose protocol demultiplexing is needed, you can still classify traffic from
CE into different type and associate a disposition label with each type.  In the
hardware or software, each disposition label is associated with an action
function which can be tailored for each traffic type.  Therefore, the label
already embeds the protocol semantics and there is no need to have another field
to indicate the protocol type.  Did I miss something?

---Wei

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 30 Jul 2003 13:21:58 -0700

Mustapha,

As I mentioned during the meeting and as mentioned in my draft, there is a 
L3 dependancy on L2 interfaces and therefore supporting multiple protocols 
between two heterogeneous ACs is not as simple as just coming up with PID 
assignment. In your example of FR and Ethernet interfaces having IP and 
IS-IS on top of them, the IP requires ARP mediation and IS-IS simply 
doesn't work in your example - take a look at arp-mediation draft.

-Ali