Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt

From: Mourad BERKANE <[email-masked]>
Date: Tue, 29 Apr 2003 13:55:06 +0200

Robert et al.

As you hinted here, MP-BGP is much more designed for a *public* inter-AS
session for VPLS.

Even if LDP/RSVP already present for the forwarding plane inside a MPLS
domain, why should i used LDP for VPLS signalling when BGP already do the
job (IPv4,v6,rfc2547bis,...)???

Mourad

-----Message d'origine-----
De : Robert Raszuk [mailto:[email-masked]]
Envoyé : mardi 29 avril 2003 11:26
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt

Andres,

AFAIK there is no need to configure anything rather then a site
interface on the PEs. Autodiscovery will detect new addition and
propagate the news to all participants. Then in the lasserre-vkompella
scheme directed LDP if not already set get's automatically established
between parties. 

Of course the drawback here is that you need to keep LDP ports open wide
within inter-AS LDP src ranges which may or may not be an acceptable
issue :-).

R.

> [email-masked] wrote:
> 
> Hi Eric
> 
> As I understand it a requirement would be to have a full mesh of LDP
> sessions between the PEs in the participating AS domains. This means
> configuration of each PE when for example a new site is added to an
> already existing VPN. If BGP is used this is not necessary as RRs can be
> used, minimizing the configuration to the new PE and the RR.
> But perhaps there exist a solution similar to this for LDP as well? It
> seems appealing to reuse the 2547bis structure we have also for VPLS if
> it's possible.
> 
> My point is that further investigation of the two different solutions
> before rejecting one or the other would be good
> 
> /Andreas
> 
> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: den 28 april 2003 16:29
> To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67
> Cc: [email-masked]
> Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt
> 
> Andreas> I would  also like to  know how inter-AS  with the LDP
> Andreas> approach in lasserre-vkompella is to be solved.
> 
> Could you say what the issue is that you think needs to be solved?

---

From: [email-masked]
Date: Tue, 29 Apr 2003 14:19:09 +0200

Mourad,

> As you hinted here, MP-BGP is much more designed for a *public*
> inter-AS session for VPLS.

I still don't understand why MP-BGP is more appropriate than LDP for
this application. I probably need more than a "hint" to fully understand
it ;-)

> Even if LDP/RSVP already present for the forwarding plane inside a
> MPLS domain, why should i used LDP for VPLS signalling when BGP
> already do the job (IPv4,v6,rfc2547bis,...)???

You can turn this around: Even if BGP is already present for 2547bis,
v4, v6 etc, why should I use BGP for VPLS signaling when LDP already
does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3
Pseudo-Wires, ...) ?

[I guess the answer to both of the above questions is given in the large
number of previous emails on this topic ;-)]

Jeremy.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 29 Apr 2003 14:22:02 +0200

Well I am taking a higher level view and honestly I am not biased
towards either BGP or LDP used for signaling. In fact as I said both
should proceed forward especially in the VPLS application. 

Now reg your comment that BGP is more designed for a public inter-as I
can only agree ;). Coming very soon for BGP MD5 key exchanges
improvements for operators making something hard to exchange today will
be much easier tomorrow. 

With LDP any serious deployment should consider MD5 and correlation of
all the keys on ALL of your and your peers PEs will be by all means much
more challenging exercise :). Using blank directed LDP without
protection could be fine within AS but inter-as (even to your trusted
peer ... I don't know). And of course fact that you run LDP for regular
forwarding or not is pretty much orthogonal to the exercise here.

Cheers,
R.

> Mourad BERKANE wrote:

---

From: "Mike Duckett \(Dotnet\)" <[email-masked]>
Date: Tue, 29 Apr 2003 08:32:22 -0400

RE: Support for draft-kompella-ppvpn-vpls-01.txtMourad,

You have asked THE question.  What problems do we need to solve that drive us to a something that BGP cannot perform?   Is BGP sufficiently robust that we believe future unknowns can be sufficiently addressed (intentionally vague)?  Are there capabilities that require protracted negotiation specific to a limited set (e.g., a pair) of PEs?  

  ----- Original Message ----- 
  From: Mourad BERKANE 
  To: [email-masked]' ; [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Tuesday, April 29, 2003 7:55 AM
  Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt

  Robert et al. 

  As you hinted here, MP-BGP is much more designed for a *public* inter-AS session for VPLS. 

  Even if LDP/RSVP already present for the forwarding plane inside a MPLS domain, why should i used LDP for VPLS signalling when BGP already do the job (IPv4,v6,rfc2547bis,...)???

  Mourad 

  -----Message d'origine----- 
  De : Robert Raszuk [mailto:[email-masked]] 
  Envoyé : mardi 29 avril 2003 11:26 
  À : [email-masked] 
  Cc : [email-masked]; [email-masked] 
  Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt 

  Andres, 

  R.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 29 Apr 2003 10:34:21 -0400

Mourad> MP-BGP is  much more  designed for a  *public* inter-AS  session for
Mourad> VPLS. 

Could you tell us exactly which features of BGP you are referring to here? 
Please be specific. 

Mourad> Even if LDP/RSVP  already present for the forwarding  plane inside a
Mourad> MPLS  domain, why should  i used  LDP for  VPLS signalling  when BGP
Mourad> already do the job (IPv4,v6,rfc2547bis,...)??? 

In  several previous messages,  I tried  to give  some specific  examples of
signaling interactions that BGP cannot do or cannot do well. 

Mourad> LDP is not used as a signaling protocol for IPv4, 

I don't know  why you would say  this.  LDP is primarily used  today to bind
MPLS labels to IPv4  routes.  I'm not sure why you say it  is "not used as a
signaling protocol for IPv4".  

Mourad> or  rfc2547bis :-)  BGP is  in charge  of it  (and do  the  job very
Mourad> well). 

So, if BGP is  good for 2547, it must be good for  VPLS too?  Isn't that the
issue under discussion?

---

From: "Vach Kompella" <[email-masked]>
Date: Tue, 29 Apr 2003 08:55:41 -0700

Robert,

> improvements for operators making something hard to exchange today will

The MD5 protection is at the TCP level, not at the BGP level.  LDP security
through the use of MD5 is advocated in RFC3036.  I would, of course, prefer that
IPSEC be used, but the argument there is that TCP MD5 exists and works fine.

> forwarding or not is pretty much orthogonal to the exercise here.

My last discussion with some graybeards at the IETF showed that there was no
strong inclination towards using MD5 inter-AS for BGP.  Does this persist?

> R.

-Vach

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 29 Apr 2003 18:04:04 +0200

Vach,

> IPSEC be used, but the argument there is that TCP MD5 exists and works fine.

:) ... of course it is for TCP :)... But there could be a slight
difference in number of TCP sessions you maintain in the BGP versus LDP
proposals (especially those TCP which do cross inter-as boundary), hence
number of TCP peers you need to somehow agree on using the same keys.
Not too mention that there is clear desire to change those keys
periodically which doesn't make the key maintenance between all PEs
easier.

> strong inclination towards using MD5 inter-AS for BGP.  Does this persist?

Well at IETF I usually stay focused to talk to operators & service
providers rather then graybeards ...;)

R.

---

From: "Vach Kompella" <[email-masked]>
Date: Tue, 29 Apr 2003 09:22:25 -0700

Robert,

> periodically which doesn't make the key maintenance between all PEs

Sure, but the number of TCP connections inter-AS is as many as LDP, unless you
are telling me that eBGP uses RR!

As for the changing the keys, it's a simple instantiation of IKE.  This is just
about the simplest use of IKE/IPSEC I can think of.

> providers rather then graybeards ...;)

Actually, they were graybeard operators.

-Vach

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 29 Apr 2003 18:30:25 +0200

Vach,

> are telling me that eBGP uses RR!

What ???

Notice that in 99.9% of deployments I am familiar with each AS will most
likely use IBGP mesh to RRs within each AS and one or two EBGP sessions
between RRs or ASBRs Inter-AS.

R.

PS: No I am yet not there to suggest of using route servers for VPLS
Inter-AS and even if I would it would be for a quite a number of ASes
peering together not just 2-5 like I think in most of todays Inter-AS
cases.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Apr 2003 10:14:28 -0700

Vach,

> Sure, but the number of TCP connections inter-AS is as many as LDP, unless 
> you are telling me that eBGP uses RR!

If one would read 2547bis, then one should be able to fine the following:

     To improve scalability, one can have the multi-hop EBGP
     connections exist only between a route reflector in one AS and
     a route reflector in another.  (However, when the route
     reflectors distribute routes over this connection, they do not
     modify the BGP next hop attribute of the routes.)  

Precisely the same applies for VPLS when autodiscovery and signaling
is done via BGP.

Yakov.

---

From: Ali Sajassi <[email-masked]>
Date: Tue, 29 Apr 2003 16:53:26 -0700

Yakov,

>Precisely the same applies for VPLS when autodiscovery and signaling

No, it doesn't  !! You forgot to mention the magic word, PtP PW 
scalability, which doesn't exist in L3VPN. By connecting all the PEs of a 
VPLS instance in one AS in a full-mesh to all other PEs of the same VPLS 
instance in a different AS, you've just increased the number of PWs by 
four-folds. Now as number of ASs increases, the number of PWs increases by 
N^2. The reason for hierarchical-VPLS topology which is also referred to in 
your draft is to address such scalability issues and to reduce the number 
of PWs.

Therefore, connecting different ASes via hubs is intended to address such 
scalability issue and make the number of PWs grow linearly with number of 
ASes. So if number of PWs among ASes are small, then there is no issue with 
MD5 among small number of sessions and if the number of PWs is large, then 
you have scalability issue of PWs itsef (and maintenance of them).

Also it is interesting that how arguments switch sides :-) At one point you 
were arguing in favor of such hub scheme for different ASes with different 
signaling types (e.g., between BGP and L2TPv3/LDP) and now you're arguing 
against it :-)

-Ali