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

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 06 Aug 2003 09:09:53 -0400

Yetik,
the word "adamant" is maybe strong. I heard a couple of issues: CPE/CLE
capabilities is one of them indeed. The other one is related to the change of
configuration required on many of the existing sites.

In any case, whether a bridge encapsulation is used or not is orthogonal to the
the way a FR VC is interworked with a point-to-point Ethernet interface. The
main issue is how to carry multiple user payloads across FR-VC to PW to Ethernet
interface.

Regards,
Mustapha.
-----------
"Serbest, Yetik" wrote

> Why are your customers so adamant on not changing their encapsulations? Is
> it because their CPE does not support bridged encapsulations (like old
> FRADs)?
>
> -----Original Message-----
> From: Mustapha Aissaoui [mailto:[email-masked]]
> Sent: Tuesday, August 05, 2003 8:47 AM
> To: Ali Sajassi
> Cc: [email-masked]
> Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4
>
> Ali,
>
> Ali Sajassi wrote:
> >
> > At 02:53 PM 7/28/2003 -0400, Mustapha Aissaoui wrote:
> > >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 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.
>
> MA> I have issues with the 1-N VC-to-PW which I described in my
> earlier emails. Furthermore, I do not expect all my customers to go and
> change their encapsulations in their many sites to bridged type unless
> absolutely required.
>
> > >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.
> >
> > 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.
>
> MA> In fact, we made sure that most protocols required only a single
> word header in draft-aissaoui. This is the case of IP, IPv6, ISIS, ESIS, and
> CLNP. Only those protocols which require a OUI (e.g., MAC Types and Private
> Protocols) add a SNAP field and thus a 2-word multiprotocol header.
>
> > >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.
> >
> > 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 !!!
>
> MA> Where do you see LLC/SNAP in my draft??
>
> > -Ali
> >
> > >Thanks for the interesting exchange.
> > >
> > >Mustapha.
> > >-----------
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 07 Aug 2003 11:11:30 -0700

>configuration required on many of the existing sites.

The point is that, there are scenarios that you have to do configuration 
changes anyway such as CEs running OSPF. So if you have to do config 
changes at the CEs, you may want to do it such that you get the biggest 
bang for the buck and support all the different protocols running at the CE.

>main issue is how to carry multiple user payloads across FR-VC to PW to 

They are related because if you do bridged encapsulation, then with a 
single EoPW you can carry all theL3 protocols over it and you don't need to 
have different PWs for different L3 protocol and worry about the dependence 
of these protocols on underlying L2 media. For certain scenarios, you can 
assign a dedicated PW to IP traffic and another one to all other which 
means you will have two but not more than that :-)

At 10:20 AM 8/6/2003 -0400, Mustapha Aissaoui wrote:
>Yetik,
>the IS-IS example I have shown in my presentation in Vienna was not for an
>enterprise type network. It was for an ISP buying PoP connectivity through
>another service provider. There is a way to make IS-IS work without a bridged
>encapsulation. It is described in Section 9.3.1.1 of
>draft-lee-ppvpn-hybrid-vpls-01.txt.

You can see from this section that how messy it is getting. Now the PE not 
only needs to do ARP mediation but also it needs to do snooping of 
different messages and intercept/generate different IS-IS messages. I 
guess, one can claim that IS-IS hello messages can also be snooped, 
intercepted, and modified to please the endpoints but at what price and 
complexity. And just remember, you have to do this for every protocol that 
has procedural dependency on L2 interfaces if you don't want to touch the 
CE. If one wants to go to that extend, then he is probably better off with 
just peering with the CE and use a hybrid of L3VPN and L2VPN as described 
in the last section of my draft.

-Ali