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: "Hamid Ould-Brahim" <[email-masked]>
Date: Mon, 14 Apr 2003 13:37:43 -0400

Ali,

[clipped...]

> 
> 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.
> 

Maybe a good analogy (within the same MPLS technology)
is to look at the existence of multiple ways of distributing 
MPLS label that includes the use of BGP (and even RFC3031 
captured that: 

"THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
   DISTRIBUTION PROTOCOL.  In fact, a number of different label
   distribution protocols are being standardized.  Existing protocols
   have been extended so that label distribution can be piggybacked on
   them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]).  New protocols
   have also been defined for the explicit purpose of distributing
   labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].").

Although one may conclude that having multiple ways of
distributing labels can be redundant, I don't think it was useless 
(since later on such approach - of using BGP - was useful 
in rfc2547).

Hamid.

---

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

Hamid> Maybe a good analogy (within the same MPLS technology) is to look at
Hamid> the existence of multiple ways of distributing MPLS label

Hamid> Although one  may conclude that having multiple  ways of distributing
Hamid> labels can be redundant, I don't think it was useless (since later on
Hamid> such approach - of using BGP - was useful in rfc2547).

Generally, we  use LDP to distribute  labels that correspond  to IGP routes,
and we use BGP to distribute  labels that correspond to BGP routes.  I guess
you could  call this "multiple ways  of distributing labels", but  I think a
better thing to call  it would be "distribute the label in  the way which is
most suited to its application".  

For a  given application, an example  of multiple ways  to distribute labels
would be RSVP-TE  and CR-LDP.  Did we need both  ways?  Apparently not.  The
argument that  CR-LDP is better because  LDP + CR-LDP =  one protocol,while
LDP + RSVP-TE  is two protocols, now just  seems quaint.  Unfortunately, bad
arguments tend to recur over and over again ;-)

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 14 Apr 2003 11:19:27 -0700

Eric,

> most suited to its application".  

We use BGP to distribute labels that correspond to the information
(e.g., routes) carried in BGP. We use RSVP to distribute labels
that correspond to the information carried in RSVP.  We use LDP
when piggybacking is not possible.

And if you insist that LDP is used to distribute labels that correspond
to IGP routes, then LDP should not be used to carry label information
across AS boundaries - this should be done with BGP.

> LDP + RSVP-TE  is two protocols, now just  seems quaint.  

This is a rather poor analogy, as in the context of VPLS we are talking
not just about multiple ways of distributing labels, but whether
one always have to have one protocol for distributing labels, and
another for auto-discovery, or one protocol for both would be enough.

> Unfortunately, bad arguments tend to recur over and over again ;-)

On that I agree with you - we just disagree on what are these bad
arguments :-)

Yakov.

---

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

Hamid,

In case of RFC2547 that you are giving as an example of using BGP for 
delivery of MPLS label, it was done for a different PW type. RFC 2547 uses 
multipoint signaling mechanism for the setup of MPtP PW; whereas, for VPLS 
we are talking about using a multipoint signaling to setup PtP PW which 
frankly doesn't make sense to me. Also, we shouldn't use the argument that 
if in the past we have developed multiple standards for doing the same 
thing, we should keep doing it in the future.

-Ali

---

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

Eric,

[clipped...]
 
> 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. 

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).

> 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.

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

Yakov.

---

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

Ali,

> Please refer to my comments inline ...
> 
> At 10:48 AM 4/14/2003 -0700, Kireeti Kompella wrote:
> >Hi Ali,
> >
> >On Mon, 14 Apr 2003, Ali Sajassi wrote:
> >
> > > 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.
> >
> >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.
> 
> 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. 

That is quite clear :-( 

> 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. 

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

> Also having the flexibility to 
> offer different auto-discovery mechanism to the SPs.

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).

> >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.
> 
> 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.
> 
> 
> >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.
> 
> 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 !!

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.

> 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 ?

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.