Subject: Some issues with draft-ietf-pwe3-control-protocol

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Sep 2002 09:11:26 -0400

I  wonder if  we  can  get some  discussion  going on  some  aspects of  the
LDP-based signaling as specified draft-ietf-pwe3-control-protocol-00.txt.

Sometime after  this work  was substantially done,  it became clear  that it
couldn't support  many of the  L2VPN provisioning models being  discussed in
PPVPN.   The issues  are detailed  in draft-rosen-ppvpn-l2-signaling-02.txt,
which proposes  some relatively minor  extensions in order to  address these
issues, and  then shows how the extended  protocol can be used  to support a
variety of PPVPN provisioning models. 

The  basic  issue with  draft-ietf-pwe3-control-protocol-00.txt  is that  it
requires  each endpoint  of  a pseudowire  to  be configured  with a  32-bit
identifier for that pseudowire, a  "VCid", which needs to be unique relative
to  the  LDP  session between  the  two  endpoints.   This  is fine  if  the
provisioning model is that you  configure each individual pseudowire at both
of its  endpoints.  It doesn't  work so well  if one wants to  configure the
pseudowire  at  only one  of  the  endpoints, or  if  one  wants  to use  an
auto-discovery procedure to determine in  real time how many pseudowires one
needs to create  and where they are to terminate.   The latter especially is
crucial  to  most of  the  provisioning  models  being discussed  in  PPVPN.
Another issue with the VCid is that its 32-bit length is too short to permit
it to hold the sort of  structured identifier that is usually used to ensure
uniqueness in inter-provider scenarios.  For  example, one could not make an
RFC 2685 VPN-id part of the VCid.

The proposal is to  add a new FEC type in which the  VCid is replaced with a
more general  method of identification.   The paradigm is that  a pseudowire
connects two "Forwarders", and during pseudowire setup one Forwarder has to
identify  the other  Forwarder,  rather  than both  having  to identify  the
pseudowire.  Details are in the draft. 

In the  long run, perhaps the  protocol details (if accepted)  would have to
move  into  this WG,  while  the  "how to  use  the  protocol  to support  a
particular provisioning model" material would remain in PPVPN.

Another, more minor, issue  with draft-ietf-pwe3-control-protocol is that it
shows something of a tendency to use the "interface parameters" field of the
VC  FEC TLV  to  hold parameters  that  would be  better  coded as  separate
parameter TLVs (so as not to be part of the FEC).