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

From: Mustapha Aissaoui <[email-masked]>
Date: Fri, 18 Jul 2003 10:06:15 -0400

Eric,

Eric Rosen wrote:
> 
> Wei> First  of all,  what is  the  need to  demultiplex different  protocols
> Wei> carried in one  DLCI to different PWs?  Is it because  you want to send
> Wei> them to  different destinations?  Not  sure if the current  FR switches
> Wei> (PEs) for legacy L2VPNs can demultiplex packets from a single DLCI into
> Wei> different PVCs.
> 
> If  I  understand  correctly,  what   they  are  worried  about  is  service
> interworking, e.g., frame  relay on one side and ethernet  on the other.  To
> do this  kind of interworking,  you need  to be able  to tell that  a packet
> received on  the frame relay link  is, e.g., an  IP packet, so that  you can
> put on the proper IP-in-ethernet encapsulation at the other end.
> 
> One can't say this is "useless", the use is clear enough.  But:
> 
> - As Tom points out, service interworking is out of scope.

There was good support to start service interworking in the L2VPN WG
meeting yesterday. If this happens, clearly the encpasulation and
signaling parts are part of the PWE3.

> 
> - There are  other methods of  doing service interworking (such  as carrying
>   the  Frame  Relay  encaps  across   the  pw,  and  then  doing  "ordinary"
>   FR-to-ethernet  translation  at  the   other  endpoint),  and  there's  no
>   consensus within the WG of the best way.

In my presentation, I mentioned three options:
a. extend FR or Ethernet to the remote PE. This is a valid solution
and should be supported. The problem is there are more and more
Ethernet/MPLS PE products out there which do not implement anything
about FRoMPLS, let alone FR-Ethernet interworking.
b. split the FR VC into multiple parallel PWs (1-to-N). I guess the
implementation complexity and troublshooting complications of this 
solutions are obvious.
c. The PID translation between FR, PW, and Ethernet. In my view this
is the most straighforward solution. It does not change the
forwarding paradigm because it is still based on the label. It only
tranlates a PID in the paylod between FR and PW or FR and Ethernet.

> - There are other possible methods of demultiplexing, using MPLS labels.
> 
> However, without a charter change, discussion of this topic is academic.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 18 Jul 2003 10:29:15 -0400

> signaling parts are part of the PWE3. 

Sure, if  service interworking is  added to the  charter then we'll  need to
consider it. 

> about FRoMPLS, let alone FR-Ethernet interworking.

What about doing the translation to  ethernet formats at the FR end? I don't
think we're ready to rule this out.

> implementation complexity and troublshooting complications of this 

No,  I   don't  think  that  this   is  obviously  more   complex  than  the
alternatives. 

I can see  an issue in having  to maintain state for an  increased number of
pws, but a  slight alternative might be  to allow more than one  label to be
used per pw, with the  different labels invoking different encapsulations at
the  receiving endpoint.   (This  would be  something  like having  multiple
streams on a pw, with an MPLS label for each stream.)  

> forwarding paradigm because it is still based on the label. 

Well, it's another  thing that has to  be looked up at the  egress PE before
you can send the frame out to the CE, so I think it IS a modification to the
forwarding paradigm. 

My real worry about this alternative is that it might just be the tip of the
iceberg; I don't  think we want a large "how to  interwork FR with ethernet"
project in the IETF.

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 31 Jul 2003 06:11:04 -0700

>signaling parts are part of the PWE3.

If I remember correctly, there was a good support to take care of L2VPN 
scenarios with disparate interfaces and this doesn't necessarily mean 
service interworking.

>tranlates a PID in the paylod between FR and PW or FR and Ethernet.

All these scenarios plus more have been described in 
draft-sajassi-l2vpn-interworking and as  I said before it is not as simple 
as just getting PID assignment for different protocol types coming over 
disparate interfaces !!! You need to pay attention to the dependency 
between L3 protocol and the underlying L2 transport and its ramification.

-Ali