RE: decisions on L2 solutions documents

RE: decisions on L2 solutions documentsHamid,

Two meta-points.  First, Eric has resubmitted his draft to ppvpn as
draft-rosen-ppvpn-l2-signaling-03.txt.  Second, why have two FECs for PWE3?
Surely, if we use the Generalized ID FEC, then we don't need fec type 128.
Let's simplify.

I have no problem with the "Generalized ID FEC TLV" concept.  In fact, we
are probably in violent agreement on that.  The (minor) issue is what it
looks like:

AGI: <type> <octet-string>
VPN ID TLV: <type> <length> <octet-string>

But where I have considerably more difference of opinion is how to name a
PW.  In a VPWS or a VPLS, I would like to be able to name each constituent
PW.  So, I want a VPN ID that contains a number of PWs.  pwe3-control says
use a 32-bit number that is unique between a pair of PEs.  It also qualifies
that 32-bit number with a VC type.  That's probably not necessary, and some
of the implementations that I have had the pleasure of working with agree
with me.  In other words, a PW is named (PE1, VC type, VCID, PE2).

I would suggest that the full name of a PW is {VPNID (PE1, VC type, VCID,
PE2)}.

draft-rosen suggests that a PW is named (PE1, SAII, TAII, PE2).  I am not
not convinced of the benefits of this naming scheme.  Eric and I have
exchanged some emails in this regard, and are continuing to do so.

Finally, draft-rosen says the SAII and TAII are 0 for VPLS.  That means that
there is no name for the PW between a pair of VPLS nodes.  That may
generally be ok since the full name of a PW is {VPNID, (PE1, 0, 0, PE2)} and
we generally have only a single PW between a pair of nodes in a VPLS.

However, when we have a VPLS node which has a pair of spokes to the same MTU
(HVPLS situation), we have to name the PWs differently.  This scenario comes
up in certain regulatory environments where the MTU owner is only allowed to
provide L2 transport service.  Consider the following physical topology.

   CE1------------MTU-------------PE
                   |
   CE2--------------

In an unregulated case, the MTU could host a FIB, and turn packets around
between the two CEs.  However, in a regulated environment, the PE may have
to host the FIB.  We have then two spokes from the PE to the MTU, one for
CE1 and one for CE2.


   CE1------------\    /-----------\
                    MTU             PE
   CE2=============/  \=============/

I want to be able to name each spoke.  On the PE side, I have a FIB.  In
draft-rosen, the PE would name the SAII 0.  The PE would have to know the
name of the TAII on the MTU going to CE1.  The PE would have to know the
name of the TAII on the MTU going to CE2.  Otherwise, there would be no
names for these two PWs.

In summary:
 - my proposal would remove the limited use Group ID field (actually, Eric
pointed out I had no use for it)
 - my proposal requires a VPN ID that groups PWs across the network that
belong to the same VPN
 - my proposal uses the VCID field to name a PW within the VPN
 - the delta between existing fec type 128 in pwe3-control and my proposal
is minimal
 - I feel that draft-rosen suggests a much broader change (with additional
benefits, but do we need them?)

-Vach

  -----Original Message-----
  From: Hamid Ould-Brahim [mailto:[email protected]]
  Sent: Friday, May 30, 2003 10:37 AM
  To: [email protected]; Vasile Radoaca; Dinesh Mohan; Ppvpn; Rick
Wilder
  Subject: RE: decisions on L2 solutions documents


  Vach,

  A comment on vpn-id/martini...

  > Vach>> naming the PWs, not in naming the VPN ID.  The issue
  > of using a globally
  > unique name for the VPLS
  > Vach>> has been discussed.  In an attempt to keep the
  > signaling compatible with
  > draft-martini, we agreed
  > Vach>> on using a VCID.

  I think in the pw control draft (draft-ietf-pwe3-control-protocol-02.txt),
  Eric's signaling extensions have been added that can
  accommodate as well a global unique id. Why not use
  the control draft extensions.



  >However, there was an intent all
  > along to somehow make
  > that identifier a
  > Vach>> globally unique.  Suggestions were made such as adding
  > a VPN ID in the
  > optional parameters field,
  > Vach>> etc.  My last proposal was to have a bona fide VPN ID
  > TLV in the FEC.
  >

  Yes. But that is not defined in pwe control draft and if added
  it looks redundant to Eric's additions. I requested before
  clarifications on the use of VPN-ID TLV (which was left
  unanswered btw - see the archive)


http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&O=
A&P=980.

  I don't see why we still didn't resolve that problem.

  Why not just adopt the pwe3 control draft's Generalized ID
  FEC element instead of defining another VPN-ID TLV
  (which I assume if done needs to be captured in the same
  draft).

  Is there any reason why not?

  Hamid.