Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 20 Mar 2003 15:29:33 -0800 (PST)

Hi Vach,

A couple of high level comments and then please see inline:

- IMHO the WG should move in the direction of making 'one' LDP signaling
solution, a BGP signaling solution, a L2TP signaling solution and if
there is enough interest a radius signaling solution WG documents. LDP,
BGP and L2TP signaling solutions have their own merits/demerits and
fulfill different needs. 

- draft-lasserre-vkompella-...is a good starting point for a LDP
signaling solution. The major caveat is VPLS/L2-VPN identifier. (Please
see inline) With a common understanding of the how this issue should be
addressed IMHO draft-lasserre-vkompella...should be made a WG doc.

On Wed, 19 Mar 2003, Vach Kompella wrote:

> Having been asked to request comments on the ppvpn mailing lists minutes ago,
> I'm soliciting your comments.  Rather than just throwing the questions to the
> WG, I've added a couple of my thoughts as a starting point for discussion.
> 
> The points raised in the WG are:
> 1. how to differentiate between a signaled vpls and vpws if the vc type is going
> to be the same?
> 2. how to name a vpls?
> 
> For point 1, there are three approaches:
>  - go back to using different vc types.  The problem is that the vc type relates
> closely to the PW whose behavior is identical to the ethernet vc and the service
> property is above the encapsulation behavior.
>  - use a different fec type.  draft-martini uses fec type 128, draft-rosen (now
> merged into the WG version of draft-martini) uses fec type 129.  VPLS could use
> fec type 130.
>  - use a flag in the fec tlv to differentiate between vpls and vpws.  In that
> case, we could use fec type 129 and a flag for vpls vs. vpws.
> So I'd like to get some feedback on one of the three above, for starters, or
> some other approach, too.
> 

A local PE clearly has to know if the remote PE is capable of doing MAC
address learning over a PW that it has signaled. Else it cannot use that
PW for sending VPLS traffic to the remote PE. Hence the differentiation
you talk about is needed and that is what I meant to convey in my comment
in the WG meeting. Its preferable to convey this in the FEC and it
probably relates to issue #2, though I don't have a strong opinion. 

> For point 2, I propose the following:
> A VPN ID TLV formatted something like:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | VPNID TLV     |               Length          |  VPNID Type   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    ~                     VPN ID (variable length)                  ~
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The VPN ID Type could then identify the value as any one of flat 32-bit ID,
> route target, OUI-based VPN ID (rfc2685), other types (including AGI, SAII, TAII
> as used in VPWS for draft-rosen).
> I'd like some feedback on this too.
> 

This seems to be in the right direction and leaves room for extensibility
etc.  I would also like to suggest that we come up with a VPLS/L2-VPN end
identifier draft. It will briefly describe the VPN ID TLV format and
suggested semantics for a VPLS, L2VPN and colored pool application.  
draft-lasserre-vkompella...and the L2TPv3 signaling draft can then simply
treat the end ID as an opaque object and refer to this draft. This has the
following advantages:
  - Consistancy between LDP and L2TPv3 signaling as far as the end
identifier goes. Coming from a vendor that is implementing both these
approaches, this is very helpful.
  - From what I can gather there is contention with respect to the end
identifier format and that is one of the reasons why
draft-lasserre-vkomplella is facing some resistance as far as the LDP
solution goes. Decoupling this from draft-lasserre will help move things
forward. 

Comments ?

> Having said that, there are probably other issues that may have been irritating
> you that you'd like to bring to the table - let's talk about them.  My only
> comment on this process is that there is more consensus than is apparent, and
> we'd like to get a pretty good solution out there, even if it is not perfect.

Agreed !

Thanks,
rahul

> -Vach

---

From: [email-masked]
Date: Mon, 24 Mar 2003 14:33:47 +0100

Rahul, Vach, 

why is there a need to differentiate explicitly between point-to-point
and VPLS Ethernet PW signalling ? Isn't this done implicitly as the
signalled VPN ID (or VC ID) is assigned at both sides either for VPLS or
for p2p PW ?

thanks,
Jeremy.

> addressed IMHO draft-lasserre-vkompella...should be made a WG doc.

[...]

---

From: Wei Luo <[email-masked]>
Date: Mon, 24 Mar 2003 11:29:46 -0800

Rahul,

> probably relates to issue #2, though I don't have a strong opinion.

What's the reason the local PE has to know whether the remote PE is capable of
learning MAC address or not?  Isn't that some matter of the remote PE?

In the actual ethernet environment, an ethernet switch does not have to know
whether it connects to another ethernet switch (capable of learning MAC address)
or a dumb repeater (incapable of learning MAC address) on the other side of the
wire before it sends/receives traffic to/from it.  Do we need to make VPLS
different from it?

---Wei

---

From: Eric Rosen <[email-masked]>
Date: Mon, 24 Mar 2003 14:33:53 -0500

With the criterion being that the document is a suitable basis upon which to
continue  the work,  I think  this should  be a  working group  document; it
certainly meets this criterion.  

On some specific issues:

Vach> 1. how to  differentiate between  a signaled vpls  and vpws if  the vc
Vach>    type is going to be the same? 

The short answer is that if you want  to connect a PW to a VPLS VSI, you use
the signaling  to identify that VSI.   If you want  to connect the PW  to an
Attachment  Circuit  (VPWS),  you   use  the  signaling  to  identify  that
Attachment  Circuit.   If  the  difference  has  to do  with  what  you  are
connecting  to, rather  than  what  encapsulation you  are  using, then  the
difference should be reflected in how you identify the forwarder, not in the
type of PW.

But  I think  that  in Hierarchical  VPLS,  there is  a  further issue.   In
Hierarchical VPLS, a PW can fall into one of the following classes:

a. it's a Hub-Hub PW, i.e., it connects two Hub VSIs

b. it's a Hub-Spoke PW, i.e., it connects a Hub VSI to a Spoke VSI

c. it's an "Attachment PW", i.e, it connects an Attachment Circuit to a VSI,
   where the AC and the VSI are on different PEs

A Hub VSI must be able to  distinguish the set of Hub-Hub PWs from the other
PWs,  so that  it  can correctly  apply  split horizon  to  the Hub-Hub  PWs
only.  So  in  Hierarchical VPLS,  you  need  to  know something  about  the
forwarder that the remote endpoint is connected to. 

I think the most natural way to handle this in LDP would be with an optional
TLV whose semantics are "I am a hub VSI".  

Vach says we  need to distinguish between VPLS and  VPWS, which is different
than  distinguishing between  Hub-Hub PWs  and  other PWs.   So perhaps  I'm
misunderstanding the problem, or looking at a different problem.

Vach> For point 1, there are three approaches: 

Vach> - go back  to using different  vc types.  The  problem is that  the vc
Vach>   type relates  closely to the PW  whose behavior is  identical to the
Vach>   ethernet  vc and  the service  property is  above  the encapsulation
Vach>   behavior. 

I don't like  this approach; a single  PW type should be able  to connect to
different sorts  of applications (i.e.,  to different sorts  of forwarders).
We don't  want to have to  invent a new PW  type every time we  devise a new
PW application. 

Vach> - use  a  different  fec  type.   draft-martini  uses  fec  type  128,
Vach>   draft-rosen (now  merged into the WG version  of draft-martini) uses
Vach>   fec type 129.  VPLS could use fec type 130.

A  FEC type  is  really a  specification  for identifying  a  PW (i.e.,  for
identifying the forwarders  to which the PW attaches).  So  I don't think we
want to add another FEC type  unless we add a fundamentally different way of
identifying forwarders.   FEC 129 was added  because FEC 128  uses a single,
fixed length, 32-bit identifier to identify the forwarders, and we wanted to
be able to use variable length identifiers instead.

Vach>  - use a flag  in the fec tlv to differentiate  between vpls and vpws.
Vach>    In  that case,  we  could use  fec type  129  and a  flag for  vpls
Vach>    vs. vpws.

A flag in the FEC TLV  (or something in the "interface parameters") would be
appropriate if we want to make sure that  the PW does not get set up if both
sides don't agree in advance on what  kind of forwarder is at the other end.
On the  other hand, if we want  to be able to  discover dynamically (through
the signaling) what type of forwarder is at the other end, we would need the
optional TLV (not part of the FEC TLV) that I mentioned above. 

Vach> 2. how to name a vpls? 

Vach> A VPN ID TLV formatted something like:

Vach>     0                   1                   2                   3
Vach>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Vach>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vach>    | VPNID TLV     |               Length          |  VPNID Type   |
Vach>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vach>    |                                                               |
Vach>    ~                     VPN ID (variable length)                  ~
Vach>    |                                                               |
Vach>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vach> The  VPN ID Type  could then  identify the  value as  any one  of flat
Vach> 32-bit  ID, route  target,  OUI-based VPN  ID  (rfc2685), other  types
Vach> (including AGI, SAII, TAII as used in VPWS for draft-rosen). 

My take  on this is  the following.  A  protocol which creates  a connection
between two  things needs some way  to identify those two  things.  When the
connection is a PW, the two things are forwarders.  

In VPLS and Hierarchical  VPLS, when the PW connects two VSIs,  we can use a
single VPN-id  to identify both VSIs.   (This works because a  single PE can
have  only one  VSI  for a  given VPLS.)   However,  if the  PW connects  an
attachment circuit to a remote VSI, one forwarder will have a "VPWS name" of
some sort, while  the other will have  a VPLS name.  In VPWS,  the names are
likely to  be different at the  two endpoints; in distributed  VPLS or GVPLS
the names are likely to be different, but related. 

To  try to  accommodate  all this  in a  general  way, I  proposed that  the
identifier field should be specified  as a triple: <common part, local part,
remote part>, where  one of the Forwarders has the  name <common part, local
part> and the other  has the name <common part,  remote part>.  (Others have
objected that  the identifier should  simply consist of  a local name  and a
remote name, without a separate common part.  That would work too, though in
some cases you might just end up encoding a common part into both names.)

In the  case of  VPLS or Hierarchical  VPLS VSI-to-VSI signaling,  the local
part and remote part could be omitted, and the common part would be the VPLS
identifier.  In the case of  Attachment Circuit to VSI signaling, the common
part would still  be the VPLS identifier, but the  local part (for signaling
in the "towards  the VSI direction") would be a  "VPWS name" identifying the
attachment circuit.   I'm not  sure how Vach  proposes to handle  this case;
perhaps he  is thinking  that the signaling  should be pure  VPWS signaling,
with the  PW connecting a real  attachment circuit to  a "virtual attachment
circuit", where the virtual  attachment circuit attaches by configuration to
the  VSI.    This  would   certainly  work,  but   seems  to   require  more
configuration. 

Vach's proposal and  mine differ in the way the  identifiers are encoded.  I
proposed a three-part  encoding, with null values for  any parts that aren't
used.  Vach  proposes a  VPNid Type field,  which says (among  other things)
whether the identifier  has one part, two parts, three  parts, etc.  I don't
really care very much about that particular coding detail, but I do think we
need  a  common understanding  of  how  we signal  a  PW  which connects  an
attachment circuit to a remote VSI.

I  continue to  believe  that section  7  of draft-laserre-vkompella  should
largely  be replaced with  references to  the PWE3  and L2TP  documents that
specify the signaling.

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 24 Mar 2003 13:24:39 -0800 (PST)

Hi Eric,

[clipped]

> optional TLV (not part of the FEC TLV) that I mentioned above. 

Its good to retain the option of not setting up a PW if the two sides do
not agree on the forwarder on either end. The forwarder could be an
attachment circuit, VSI, spoke/hub attachment etc. Encoding this in the
interface parameters seems like a good idea.

> attachment circuit to a remote VSI.

I agree with this. The key is to have a common understanding. Having the
vpn-type field adds flexibility to the encoding.

> largely  be replaced with  references to  the PWE3  and L2TP  documents that

Wouldn't it be even better to have a common document (for LDP, L2TPv3)
that specifies the identifier encoding and possibly signaling ?

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 24 Mar 2003 13:30:56 -0800 (PST)

> learning MAC address or not?  Isn't that some matter of the remote PE?

There is no reason for the local PE to flood packets over the PW if the
other end can't really participate in the VPLS over that PW.

> wire before it sends/receives traffic to/from it.  

Do we need to make VPLS
> different from it?

The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the
forwarder capabilities on that PW can help in flooding optimization, split
horizon checks and adds robustness. IMHO there is no point in bringing up
the PW if the forwarder capabilities at either end don't match..

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 24 Mar 2003 13:34:08 -0800 (PST)

> signalled VPN ID (or VC ID) is assigned at both sides either for VPLS or

We shouldn't rely on the identifier semantics to convey the type of the
forwarder. One end may be an attachment circuit and the other a VSI with
the PW signalled using the same identifier.

regards,
rahul

---

From: Wei Luo <[email-masked]>
Date: Mon, 24 Mar 2003 14:53:03 -0800

> other end can't really participate in the VPLS over that PW.

For unknown unicast and broadcast packet, you will have to flood it regardless
of the capability of the remote end, won't you?  Otherwise, you lose packets and
have a connectivity problem.

> the PW if the forwarder capabilities at either end don't match..

Shouldn't we use some kind of capability TLV in this case, which has more
extensibility and better semantics than PW type?

---Wei

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 24 Mar 2003 16:54:26 -0800 (PST)

> have a connectivity problem.

Agreed. But if the other end can't learn over that PW, its not really
participating in the VPLS..

> extensibility and better semantics than PW type?

Very true. This was well summarised by Eric in his response on this
issue..

rahul

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 24 Mar 2003 23:23:33 -0800

>misunderstanding the problem, or looking at a different problem.

Eric, you're right on the money. One additional comment that I'd like to 
add is that the split-horizon for hub-to-hub PW is really a local function 
and it should be configured locally. However, the remote-end indication 
would provide additional check for the other half of the PW. If the two 
halves have the same setting/indications and it is consistent w/ local 
config, then the PW should be established; otherwise, it should not.

Also this type of check would be viable for symmetric connection (e.g., PtP 
PW) and not for asymmetric connections such as PtMP or MPtP PWs. Even for 
symmetric connection, if the operator makes double errors, then it cannot 
be detected.

So signaling "I am a hub VSI" during PW setup can be helpful for HVPLS but 
it has its limitations.

>attachment circuit to a remote VSI.

Using a VPN-id with three parts identifier (e.g., SAII, AGI, and TAII) 
doesn't fit well since VPN-id is intuitively associated with a common 
identifier (AGI). So I would favor the first approach of having three-part 
encoding with null values for any unused parts.

>largely  be replaced with  references to  the PWE3  and L2TP  documents that

Yes, given that PW signaling is covering it, we should leverage it for HVPLS.

-Ali

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 24 Mar 2003 23:38:03 -0800

>the PW if the forwarder capabilities at either end don't match..

There are valid HVPLS scenarios where the forwarder capabilities at the two 
ends don't match - e.g., PW connection between PE-r and PE-rs. The setting 
of split-horizon capability is a local matter; however, providing forwarder 
capability indication provides additional check. In other words, for a PW 
to become active, then:

a) if it is configured locally w/ split horzion, then both halves of PWs 
need to indicate VSI capability
b) if it is not configured locally w/ slit horizon, then one half of PW 
need to indicate non-VSI capability

As I mentioned earlier this checking is valid  for symmetric PtP PW and for 
detecting a single operator error (not for double error).

-Ali

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 25 Mar 2003 10:46:30 -0800 (PST)

> capability indication provides additional check. In other words, for a PW 

True. There are caveats to my statement. Probably a better way to put it
is to say that the PW should be brought up only if the forwarder
capabilities match the expected criterion, which is dictated by the
application.