Subject: Issues with draft-kompella-ppvpn-vpls-01.txt

From: Ali Sajassi <[email-masked]>
Date: Sun, 13 Apr 2003 20:06:47 -0700

There are several issues with this draft which I would like to be addressed 
first before being considered as WG document. I am copying PWE3 here as 
well because one of the issue is pertinent to them.

1) PW Signaling:
The draft suggests using BGP as signaling mechanism for Point-to-Point PWs 
of type Ethernet. The encapsulation and setup of PtP Ethernet PWs are 
already covered in the PWE3 and LDP-based signaling is the recommended 
signaling mechanism for PtP PWs in MPLS network. I don't see any benefits 
of introducing yet another signaling mechanism for this propose; however, 
the drawback of it are:

i) intertwining signaling mechanism w/ auto-discovery restricts the service 
provider to using BGP auto-discovery only - e.g. if a SP wants to use 
non-BGP auto-discovery mechanism (such as directory-based radius), then BGP 
signaling is useless. However LDP-based signaling based on PWE3 draft 
(draft-ietf-pwe3-control-protocol-02.txt) is independent from 
auto-discovery mechanism and both BGP and non-BGP auto-discovery can be 
used by it.

ii) inter-operability issues: having two different signaling mechanism for 
the same PW type and network type (e.g., EoMPLS PW), would necessitate the 
need for interworking (either at the control plane or at the date plane). 
This is an unnecessary complication which is not needed. If the 
interworking is done at the signaling level, it is tedious and 
unprecedented. And if it is done at the data-plane level, then it creates 
unnecessary scalability issues for the ASBRs.

iii) it limits all the PWs in a VPLS set to have the same characteristics.

2) MAC address flush:
This mechanism is inconsistent with 802.1D and the new proposals for 
802.1ad. The PE should NOT signal MAC address withdrawal upon link failure 
but instead it should signal it upon link activation (in case of multiple 
redundant links). The reason for this is to avoid unnecessary flooding of 
customer packets when a link failure happens without having redundant links.

3) Customer's BPDUs
There is no description of how customers BPDUs are tunneled and in case of 
back-door connection by customer, how these BPDUs are handled by the SP. 
These is important in order for the customer's network to operate properly.

Among these three issues, the PW signaling for MPLS is the bigger issue and 
I would like it to be addressed first in the PWE3 before reinventing it in 
a different form for PPVPN.

-Ali

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 14 Apr 2003 06:55:48 -0700

Ali,

> of introducing yet another signaling mechanism for this propose; however, 

You didn't mention one important point. Namely, that the draft uses
BGP for auto-discovery, and piggybacks label information (signaling)
on top of auto-discovery. So, instead of one protocol for signaling
(LDP), and another for auto-discovery (BGP) the draft accomplishes
both with a single protocol. So, why two protocols (LDP + BGP) is
any better than one (BGP) ? In addition, using BGP for both
auto-discovery and signaling, instead of using BGP for auto-discovery
and LDP for signaling, simplifies inter-provider operations, fits
into a common framework for both L2 and 2547 VPNs, etc....

Furthermore, perhaps rereading recently posted e-mails from from
several service providers who support draft-kompella-ppvpn-vpls-01.txt
may also help you to understand the benefits of the approach
described in draft-kompella-ppvpn-vpls-01.txt.

> signaling is useless. 

That is correct. But paraphrasing you one could also say that
if a SP wants to use a non-MPLS signaling mechanism, then LDP signaling,
as described in draft-lasserre-vkompella-ppvpn-vpls-04.txt, is useless. 
  
>                       However LDP-based signaling based on PWE3 draft 

I am really glad you brought up the inter-operability issue, as
draft-lasserre-vkompella-ppvpn-vpls-04.txt does not prescribe any
auto-discovery mechanism, while listing "three potential candidates,
[BGP-DISC], [DNS-DISC], [LDP-DISC]." Perhaps you could explain to
the rest of us how inter-operability could be accomplished in this case
(e.g., one vendor implements BGP auto-discovery, and another vendor
implements Radius-based auto-discovery).

> iii) it limits all the PWs in a VPLS set to have the same characteristics.

And why exactly this is a problem of *practical* significance in
the context of VPLS ?

Yakov.

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 14 Apr 2003 09:56:33 -0700

Yakov,

Please see the reply inline ...

>into a common framework for both L2 and 2547 VPNs, etc....

Yes, with tightly coupling (intertwining) auto-discovery with signaling, 
you can use one protocol for both at the expense of overloading that 
protocol even more. However, that is not my point. My point is we already 
have a singling mechanism for PtP PW as prescribed in PWE3 which is more 
flexible and more appropriate for PtP PWs and why do we need yet another 
one which doesn't offer any clear benefit and that signaling would only be 
applicable to BGP auto-discovery and doesn't work w/ any other types of 
auto-discovery.

With respect to 2547 VPN, at the surface it may look that both are similar 
but looking at it in more details, we see that 2547 uses MPtP PWs; whereas 
VPLS does not (it uses PtP). So we are talking about apple and oranges 
although it may look like apples at first :-)

>described in draft-kompella-ppvpn-vpls-01.txt.

There might be some support because lumping the signaling and 
auto-discovery together may result in quicker implementation but I would 
question the long term viability of it. I would also be interested in 
knowing how many other vendors are planning to support this draft because 
that is another factor for SPs to consider.

>as described in draft-lasserre-vkompella-ppvpn-vpls-04.txt, is useless.

That is not a good analogy. MPLS and IP are two different technologies; 
however, within the same MPLS technology having two different ways of doing 
the same thing is at best redundant and at worst useless.

>implements Radius-based auto-discovery).

Decoupling signaling and auto-discovery helps in this case since as long as 
the PEs have the endpoints identifiers, tunnels and PWs can be established 
using the same signaling mechanism. The endpoints ID can be a) configured 
manually or b) configured into the auto-discovery mechanism (e.g., into the 
DNS/Radius records).

>And why exactly this is a problem of *practical* significance in

in case you need different SLAs for different PWs - e.g., PWs between 
different sites have different QoS requirements.

Again I would like to reiterate that if we are introducing a new signaling 
for the same PW type, it should first get approved by PWE3 (since their 
charter covers maintenance/setup of PWs).

-Ali

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 14 Apr 2003 10:48:12 -0700 (PDT)

Hi Ali,

On Mon, 14 Apr 2003, Ali Sajassi wrote:

> protocol even more.

If you use BGP for auto-discovery, adding signaling information is a minor
addition with major benefits:
 o a single advertisement accomplishes both auto-discovery and signaling;
 o there is no inter-protocol dependency, and attendant complexity of
   both code and deployment/debugging/...;
 o one gets a complete solution, instead of promises to add enough to
   LDP/radius/... to complete that solution.

If the issue is "overloading BGP", it is clear that 2547 overloads BGP
far more significantly.  And implementations have proven that BGP is
nonetheless perfectly happy; deployments have shown that this
"overloading" has not resulted in any practical problems.

The fact that people who bring up this "overloading" argument forget is
that in the end, all relevant information must be communicated.  The
"overloading" of the PE in doing so does *not* decrease if you use
BGP+LDP (or radius+LDP or whatever) -- it only increases.  If you
compare the protocol state, the use of memory/CPU, the inter-protocol
interactions, etc. -- if you use any measurable criteria for the
complexity of a solution, on all these measures, the solution proposed
in draft-kompella-ppvpn-vpls is clearly superior.

> However, that is not my point. My point is we already

First of all, there are several clear benefits.  Just ask the Service
Providers who responded.

Second, a proposal that only shows how to do signaling is clearly
inferior -- so to turn your argument around, one might suggest that
the PWE3 work be scrapped in favor of a complete solution :-)  I have
no desire to suggest this, but your argument doesn't hold water.

> although it may look like apples at first :-)

Instead of playing semantic games. if you look at the service offered,
you see strong parallels -- any-to-any connectivity, learned forwarding
(as opposed to static mapping in the case of PWs).  And there are strong
parallels in how a BGP-based VPLS service and a BGP-based IP VPN service
are deployed.

> that is another factor for SPs to consider.

"Lumping the signaling and auto-discovery together" actually results
in a more coordinated implementation, not a quicker one.  And instead
of imputing reasons why SPs may like this, just read their emails and
see what they say.

Finally, to address your issues in your first email, we are not asking
that this doc be made an RFC -- just that it be made a WG doc.  As
Alex said: "For a document to become a WG draft, it doesn't have to be
100% correct."

Kireeti.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 14 Apr 2003 14:58:35 -0400

Kireeti> If you use BGP  for auto-discovery, adding signaling information is
Kireeti> a minor addition

Yeah, that's what people used to say about adding traffic engineering to LDP
;-)

When I  look at the PWE3 signaling  docs, I see that  the signaling involves
quite a  bit more than just  sending a label.  I  think you need  to look at
everything which can be signaled in PWE3  and say how you would handle it in
BGP, or else say why it is not needed. 

I  also think  that VPLS  signaling  needs to  be general  enough to  handle
certain mix  and match cases,  such as connecting  a p2p pseudowire  into an
emulated LAN.  I can  see how this can be done with  PWE3 signaling, but I'm
not sure I see how the BGP-based signaling could handle it.

Kireeti> there is no inter-protocol dependency

If you are  planning to use BGP to  set up the PE-PE tunnels as  well as the
pseudowires, I  haven't seen the  proposal for that.  Otherwise,  there's no
avoiding inter-protocol dependencies. 

In any event, auto-discovery and signaling are well-layered from each other,
and do not introduce any sort of ugly dependencies. 

Kireeti> If the issue is "overloading  BGP", it is clear that 2547 overloads
Kireeti> BGP far more significantly. 

I don't believe in the "overloading BGP" argument myself, though it is clear
that that  argument has  many adherents.   To my mind,  the issue  is really
whether BGP is  a good protocol for  the kind of signaling that  needs to be
done.  Sure, "with enough thrust, even  pigs can fly".  In 2547, we chose to
use BGP  not because it  was there,  but because it  is a good  protocol for
distributing  a large  amount of  routing information  that  originates from
other  routing   domains.   I  like   BGP  for  auto-discovery   because  in
auto-discovery,  we  want a  protocol  that  provides a  point-to-multipoint
capability and  allows an originator  to update and withdraw  information at
will; BGP  as a protocol seems  like a good match.   Is it a  good match for
point-to-point signaling?  That's a lot more of a stretch. 

Kireeti> if  you  use  any  measurable  criteria for  the  complexity  of  a
Kireeti> solution, on all these measures, 

Well, that's  the claim.  Let's see,  suppose you need  to resynchronize the
sequence numbers on a particular  PE-PE pseudowire.  How efficient is BGP at
doing that?   Suppose there is some problem  in getting data from  one PE to
another?  Does  the fact that the  control plane goes through  a third party
(route  reflector) make  it easier  to  troubleshoot that  problem, or  more
difficult? 

Kireeti> First  of all,  there are  several  clear benefits.   Just ask  the
Kireeti> Service Providers who responded. 

You're referring to the benefit of "elegance"?  

Kireeti> Finally, to  address your  issues in your  first email, we  are not
Kireeti> asking that this  doc be made an RFC  -- just that it be  made a WG
Kireeti> doc.   As Alex  said: "For  a  document to  become a  WG draft,  it
Kireeti> doesn't have to be 100% correct." 

Adopting your  document as  a WG  doc would be  an expression  by the  WG of
support for using BGP  as a way to do p2p signaling.   The WG should be very
sure that it wants to do that before adopting your doc. 

Kireeti> if you  look at  the service offered,  you see strong  parallels --
Kireeti> any-to-any connectivity, learned forwarding 

If you compare bridging to routing,  you'll see the very same parallels, yet
the technologies  are very  different, have very  different applicabilities,
and require very different solutions.

Kireeti> a proposal that only shows how to do signaling is clearly inferior 

Certainly what is  needed is a complete solution, rather  than just a piece.
However, when the solution contains multiple identifiable components, proper
layering generally results in more long term simplicity and flexibility. 

If  the proposal  is  to use  BGP  for signaling  pseudowires,  I think  the
technical discussion should focus on its suitability for that purpose. 

Yakov> in the context of VPLS we are talking not just about multiple ways of
Yakov> distributing labels, but whether one always have to have one protocol
Yakov> for  distributing  labels, and  another  for  auto-discovery, or  one
Yakov> protocol for both would be enough.

Well,  I don't  really see  how  this is  different than  the "CR-LDP  isn't
another protocol"  argument.  The arguments  are being repeated  almost word
for word, albeit not by the same set of people ;-)

You seem to be  arguing that "given a protocol to do X, if  we need to do Y,
it is better to piggyback Y on the X-protocol than to use a protocol that is
designed to do  Y."  In general, this argument form is  not valid, it really
is a matter of how suitable the X protocol is for Y. 

Yakov> The fact that the  two drafts [kompella and lasserre/vkompella] share
Yakov> the same data plane is a feature, not a bug.

Of course, I never said otherwise.  But the specification of that data plane
should not  be in both  places, one doc  should reference the other.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 14 Apr 2003 12:08:53 -0700

Eric,

[clipped...]
 
> designed to do  Y. In general, this argument form is  not valid, it really

Agreed. I guess all we arguing about is whether in the case where BGP
is used for auto-discovery BGP is also suitable for distributing labels
(note we are *not* arguing on suitability of BGP for distributing
labels when some other than BGP mechanism is used for auto-discovery).

> should not  be in both  places, one doc  should reference the other.

That would be fine with me. Or the data plane could be pulled into
a separate document...

Yakov.

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 14 Apr 2003 13:13:04 -0700

Hi Kireeti,

Please refer to my comments inline ...

>    LDP/radius/... to complete that solution.

Although BGP is a very legitimate approach for auto-discovery and a proven 
way for doing MPtP PW signaling, I don't see any benefits for VPLS type 
application where it requires signaling for PtP PWs. One can use BGP 
auto-discovery with existing LDP signaling (per PWE3) and get all the 
benefits plus more (more in the sense of having the flexibility to use 
different SLAs and QoS for different PWs. Also having the flexibility to 
offer different auto-discovery mechanism to the SPs.

>"overloading" has not resulted in any practical problems.

When I talked about overloading BGP, I was referring to overloading it more 
than we have to. 2547 is a different application with different 
requirements and it makes sense to use multipoint signaling for multipoint 
PWs but for VPLS application, the PW is of type PtP and the associated 
signaling as described in PWE3 works well for this type of PW. So using BGP 
as auto-discovery, doesn't mean overloading it for signaling as well.

>in draft-kompella-ppvpn-vpls is clearly superior.

I didn't talk about overloading the PE but instead about the protocol more 
than we have to. If we don't use route reflector, then BGP has even higher 
overhead than LDP for PtP signaling. And even with route reflector, there 
is a trade off between number of connections versus number of messages need 
to be processed between BGP and LDP signaling - so BGP has higher overhead 
in terms of packet processing than LDP !!
Also what you're going to do for the SP who don't want to use BGP 
auto-discovery (e.g., they prefer directory-based) ? Are you going to force 
them to use BGP ?

>First of all, there are several clear benefits.  Just ask the Service

I would like to ask those service providers to explain the benefits of 
using BGP for PtP signaling in VPLS applications instead of LDP as 
recommended in PWE3  ? Again I am not talking about BGP usage for 
auto-discovery as it can serve well for auto-discovery.

>no desire to suggest this, but your argument doesn't hold water.

There is a difference between a draft containing all the pieces of a 
solution versus all the pieces of a solution being available and can be 
nicely referenced in a draft (e.g., functional decomposition). So if there 
are drafts that describe PW signaling and auto-discovery, then I don't see 
any point in lumping them all in one draft. In fact we should avoid this as 
much as possible.

>parallels in how a BGP-based VPLS service and a BGP-based IP VPN service

There are also significant differences - e.g., control-plane learning vesus 
data-plane learning and connectivity among FIBs between the two. So lets 
not make a general statement that they are the same. As the matter of fact 
the PW between a pair of FIB in VPLS look exactly the same as for PW PtP 
operation (VPWS) but you cannot say the same thing for 2547.

>of imputing reasons why SPs may like this, just read their emails and

O.K., I would like to hear from them to describe the reasons in details.

>Alex said: "For a document to become a WG draft, it doesn't have to be

Yes but I am concern about PPVPN group try to duplicate the effort of other 
WG and as I said the signaling portion of PtP PW falls within the charter 
of PWE3.

-Ali

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 14 Apr 2003 13:50:40 -0700

Ali,

> application where it requires signaling for PtP PWs. 

That is quite clear :-( 

> One can use BGP 
> different SLAs and QoS for different PWs. 

You've yet to show that in the context of VPLS this flexibility 
is of any *practical* significance.

> Also having the flexibility to 

This seems like trying to optimize from a vendor's perspective.
So, just say so.

However, one may also consider trying to optimize from a service
provider perspective (the two are not always the same).

> in terms of packet processing than LDP !!

To get the overall picture one needs to compare BGP for both
auto-discovery and signaling vs BGP for auto-discovery + LDP for
signaling, and *not* BGP vs LDP just for signaling. Comparing just
BGP for signaling vs LDP for signaling is quite misleading, as it
ignores the fact that auto-discovery is an essential part of VPLS.

> auto-discovery (e.g., they prefer directory-based) ? Are you going to force 

draft-kompella-ppvpn-vpls-01.txt isn't intended to be "all things for
all people". But paraphrasing your question, what you're going to do
for the SPs who don't want to use LDP for signaling (e.g., they prefer
BGP, as they use BGP for auto-discovery) ? Are you going to force them 
to use LDP ? As I said before, it is time to realize that "one size 
doesn't fit all".

Yakov.