Subject: RE: Ethernet Circuit Types

From: Giles Heron <[email-masked]>
Date: 26 Jul 2002 00:28:12 +0000

On Thu, 2002-07-25 at 23:10, Vach Kompella wrote:
> Putting Eric's and Stewart's replies together, I get the following reasoning:
> 
> A PW carries ethernet packets.  It doesn't and shouldn't care whether there are
> VLAN tags in the packets or not.  So there should be only one such.

agreed.

> The NSP at each end does care about whether there are tags and what to do about
> them.  Getting the NSP functions mismatched is a bad thing.

agreed.
 
> The signaling of which VC type to use may have an additional "which NSP should
> we use" option.  This would allow one to signal the match or mismatch of NSPs
> (not unlike whether or not one end supports the control word, or the MTU).  The
> VC is operationally down until these things are fixed because we can catch them
> at setup time rather than have them blow up in our faces at run time.

agreed - much better to catch these things at setup time.

But one thing to remember is that in draft-martini at least there isn't
a one-to-one correspondence between the VC type and the encapsulation.
For example in the ATM case there are VCC and VPC cell-relay modes, but
just one cell relay encapsulation.  Likewise the Ethernet and Ethernet
VLAN encapsulations were effectively identical (and this has been
reflected in the latest draft), however we continue to have Ethernet and
Ethernet VLAN VC types (and also Ethernet VPLS of course).

> Signaling stuff like NSPs is an L2VPN function.  Signaling stuff like MTUs is an
> L2VPN function.  Etc.  Therefore, draft-martini-trans should move to the ppvpn
> WG, and include the NSP as an interface parameter.

agreed that specifying NSPs is probably a PPVPN function.  Not so sure
about MTU etc.  That is more a property of the wire, isn't it?

And I think we still need to resolve whether to make the NSP an
interface parameter or stick with the current model where the VC type
implicitly identifies an NSP as well as an encapsulation type.

Giles

> -Vach
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Jul 2002 10:55:00 -0400

Vach> Signaling stuff like NSPs is  an L2VPN function.  Signaling stuff like
Vach> MTUs  is  an  L2VPN  function.  Etc.   Therefore,  draft-martini-trans
Vach> should  move to  the ppvpn  WG, and  include the  NSP as  an interface
Vach> parameter. 

Well,  I already  thought it  was  in the  PPVPN group,  otherwise I'd  have
submitted draft-rosen-l2-signaling to this group. 

Frankly, I  think the  distinction between L2VPN  and PWE3 was  not properly
thought out when the working groups were set up. 

A  lot of  the  PWE3 work  on  service emulation  and encapsulation  imposes
requirements on the pseudowire signaling.  But  a lot of the L2VPN work also
imposes requirements  on the pseudowire  signaling.  Those of you  active in
PPVPN know  that, although I think that  L2VPNs are clearly built  on top of
pseudowires, draft-martini-trans  is inadequate for L2VPN.   It just doesn't
support many of the provisioning models that are important to L2VPN. 

For example,  in VPLS  one doesn't  want to use  the VCid  of draft-martini-
trans, one  wants to use a  VPN-id.  But the  two forms of VPN-id  which are
most commonly discussed are the RFC2685  VPN-id, and the use of DNS names as
VPN-ids.  As these don't fit  into the draft-martini-trans VCid field, there
is a problem.

Another provisioning model discussed in PPVPN is the automatic setting up of
a full  mesh VPWS service.   This cannot  be done if  every PW must  be pre-
assigned  a VCid  at  both endpoints.   So  again draft-martini-trans  isn't
suitable as is. 

There are a number of other examples as well.

This has led to a number of signaling efforts in PPVPN: 

- Ad hoc  attempts to extend draft-martini-trans, or  to reinterpret various
  protocol fields ("maybe we can try to  stuff a VPN-id in the VCid field if
  we use part of the group-id field ...") 

- Some new  LDP-based signaling  proposals optimized  for  particular L2VPN
  uses, but  not necessarily based on draft-martini-trans  at all ("although
  VPLS is  based entirely on p2p  pseudowires, why should  the signaling for
  VPLS be related to anything going on in PWE3?")

- A proposal to use BGP to set up pseudowires

- My own attempt to extend draft-martini-trans with additional FEC types and
  procedures to better  meet the needs of L2VPN (though  some would say that
  this work belongs in one of the first two categories ;-))

But just as  signaling work done in PWE3 may not  properly reflect the PPVPN
requirements,  signaling work  done in  PPVPN may  not properly  reflect the
service emulation/encapsulation requirements discussed in PWE3. 

My own view of the desirable outcome is that we end up with one LDP-based pw
signaling protocol, and one L2TP-based pw signaling protocol, where each one
has been shown to meet the L2VPN  requirements.  It would be nice if the ADs
and WG chairs could  set up some process to help us  move in this direction,
instead of hindering us.  Unless, of course, they do not view this direction
as desirable.