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

From: Mustapha Aissaoui <[email-masked]>
Date: Mon, 28 Jul 2003 14:53:44 -0400

Eric,
draft-sajassil2vpn-interworking-01.txt has a wider scope than mine since it goes
into some of the details of the interworking. In terms of the encapsulation, Ali
proposes to use the PID field similar to the one used in GRE encapsulation.

The reason why this is not sufficient is because many protocols are carried in
RFC 2427 and 2684 by appending the organization unique identifier (OUI) to the
payload. This is certainly the case of the IEEE 802.1 MAC types and private
organization protocols. When Andy and I looked into the best way to structure
the PID, we wanted to make sure we continue to support these and to limit the
number of combinations possible to represent a single protocol.

What I would like to propose to Ali is to separate out the encapsulation and
signaling from his draft such that we progress the work here in PWE3 (assuming
the charter is modified). The other interworking aspects in his draft can be
progressed in the l2vpn WG.

Thanks for the interesting exchange.

Mustapha.
-----------
Eric Rosen wrote:

> MA> Well, what you describe here is what we do in all PWE encapsulations. We
> MA> need to interpret  the header in the received packet  in order to create
> MA> the new payload to be sent out on the outgoing interface.
>
> Correct.  But I don't care what we  do before the MPLS label goes on, I only
> care what  we do  after it  goes on, ;-)  since that's  the only  thing that
> affects the MPLS forwarding paradigm.
>
> So to be  consistent, I should advocate that all  reencapsulation be done by
> the  ingress rather  than by  the egress.   Unfortunately, this  is  not the
> position I  was taking last  week (viz., that for  FR-ethernet interworking,
> the FR side should do everything).
>
> Okay, I see  that there is an issue to be  discussed if service interworking
> gets put in the charter.
>
> Have  you  compared  your  proposal  with  draft-sajassi-l2vpn-interworking-
> 01.txt?

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 31 Jul 2003 07:47:44 -0700

>proposes to use the PID field similar to the one used in GRE encapsulation.

The draft discusses two approaches:
a) using multiple PWs
b) using multi-protocol PW

and discusses the pros/cons of each. It also clearly states an example 
where the user can just get away with just two PWs  for multi-protocol 
support (one for IP and another for non-IP based on Ethernet/bridged encap) 
by configuring IP traffic as routed and all other non-IP traffic as bridged 
encap.

At this point, I think the multiple PWs scheme is sufficient - one for IP 
and the other for non-IP traffic which is bridged encapsulated. And we 
don't need to define a new multi-protocol PW unless it is shown otherwise.

>number of combinations possible to represent a single protocol.

Are you trying to re-invent FRF8.1 !!!
If you look at the draft closely, it says that for full ATM-FR 
interworking, standard FR8.1 is recommended by extending one PW to another 
side. And for the sub-set one can use the two-PW scheme.
Also if one wanted to use multi-protocol PW, then GRE-based PID is 
sufficient since if you take a look at the FRF8.1, the LLC/SNAP field for 
the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is fixed and thus you 
don't need to send them over the PW each time.

>progressed in the l2vpn WG.

As I mentioned, at this point I think the use of multiple PWs is sufficient 
and if it is shown that a new multi-protocol PW is needed, then still I 
think GRE-based is both sufficient and efficient since we don't want to add 
a fixed LLC/SNAP header to each packet knowing that 99% of them don't 
require it !!!

-Ali

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