Subject: RE: On BGP and VPLS

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 7 May 2003 17:46:17 -0400

> -----Original Message-----
> From: Pedro Roque Marques [mailto:[email-masked]]
> Sent: Wednesday, May 07, 2003 4:59 PM
> To: Alex Zinin
> Cc: [email-masked]; [email-masked]
> Subject: Re: On BGP and VPLS
> 
> 
> Pedro Roque Marques writes:
> 
> >>> The way i see it there is an high likely-hood of this turning into
> >>> an "Yes, it is" "No, it isn't" discussion. And I'd really like to
> >>> avoid that.
> 
> >> Agreed.
> 
> Following up on my own e-mail... i don't think it is in any way
> productive to continue the discussion torwards this path.
> 
> Lets try to turn the discussion around to the positive side:
> 
> Ignore VPLS for now.
> 
> Lets define a problem:
> 
Pedro,

It is fine to ignore VPLS and work on some arbitrary problem, but since the discussion takes place on this mailing list, I suspect that in the end, we will somehow circle back to VPLS :-)

For VPLS or other L2 VPNs, the primary requirement is that for a given VPN, a PE with an attachment circuit that belongs to that VPN is able to discover the identities of the other PEs with ACs that belong to the same VPN.

I don't see what that has to do with the propagation of a database across routers.

There is a big difference between L2 VPN autodiscovery and advertizing of routes. L2 VPN parameters are static, provisioned by a service provider and relevant only to the members of the VPN. Route information is dynamic, dependent on the actual network topology and relevant to every node in the network.

It seems to me that access to a central database is a much more sensible solution for L2 VPN autodiscovery.

Peter

> 1. A database consisting on entries (key, attr) needs to be propagated
> accross routers of the same domain and accross different
> administrative domains.
> 
> 2. An given key may be originated by more than one of the
> participating systems.
> 
> 3. A key advertised via a given member of a domain depends on
> reachability to that advertiser.
> 
> Task at hand is to find a solution to the problem above.
> 
>   Pedro.
> 
>

---

From: "Bilel Jamoussi" <[email-masked]>
Date: Fri, 9 May 2003 20:47:27 -0400

As mentioned in my initial email on the thread "Re: IMPORTANT: Strategy for
VPN work in IETF"  - this re-organization is not needed and is slowing down
progress of the PPVPN WG - The chairs should be in a position to progress
the work of their WG sine the WG is still chartered.

Bilel.

-----Original Message-----
From: Rick Wilder [mailto:[email-masked]] 
Sent: Friday, May 09, 2003 4:55 PM
To: Kireeti Kompella; Alex Zinin
Cc: [email-masked]
Subject: RE: On BGP and VPLS

Kireeti,

Regarding the last part of your message, the working group chairs have been
asked to hold off of declarations of consensus on drafts in the wake of
discussions of re-organizing (ie. splitting) of the group.

Rick

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Friday, May 09, 2003 3:18 PM
To: Alex Zinin
Cc: [email-masked]
Subject: Re: On BGP and VPLS

Hi Alex,

On Fri, 2 May 2003, Alex Zinin wrote:

>  More specifically, below I tried to put together a list of concerns  
> I have about the approach described in draft-kompella-ppvpn-vpls,  
> that I would like the WG to consider.
>
>  1. Use of the NLRI field
>
>    As an IP routing protocol, BGP uses the NLRI field to carry IP
>    reachability information in the form of IP prefixes.

As an IP routing protocol, sure.  But nowhere in RFC 2858 does it say that
BGP has to only be an IP routing protocol.

Furthermore, if BGP is used for L2 autodiscovery (which is by the way a
PPVPN *Working Group* document), the exact same issue applies.

>  2. Distribution of information
>
>    When used as an IP routing protocol, BGP distributes routes among
>    all participating routers.

For 2547, you have the same issue: BGP distributes routes among *all*
participating routers, whereas only a few are really interested in them. So
why is this an issue for VPLS but not for 2547?  The distribution mechanisms
are identical.

>  3. Aggregation of information for large-scale operation

Nowhere does 2858 talk about aggregation; in fact, the notion of aggregation
is not even mentioned.

--------------

On the issues of BGP for VPLS and also of single solution vs. multiple,
there seems to me (I'm not a PPVPN WG chair!) good consensus that the WG
wants a BGP solution, and also that they want multiple solutions. Are you,
Alex, proposing to override that consensus?

The call for consensus to make the various VPLS drafts WG documents was made
over 3 weeks ago, and the call was supposed to last one week. We are thus
two weeks overdue.  I would like the WG chairs to declare what consensus
they see, keeping in mind the email that Bert Wijnen (who is a seasoned Area
Director) sent to the TE WG just today, saying:

|| But it is WG chair(s) who decide on how to gauge WG conensus.

Or, from RFC 2418:

3.3. Session management

   Working groups make decisions through a "rough consensus" process. ....
                         It is up to the Chair to determine if rough
   consensus has been reached.

Kireeti.

---

From: "Vasile Radoaca" <[email-masked]>
Date: Sat, 10 May 2003 19:57:14 -0400

Rick, Marco

  I concur with Kireeti - based on Alex previous e-mails,  a consensus
already created during the last three weeks should not be impacted by the
new re-org, which in Alex's view is more a management issue, to offload the
work of the current WG.

  Reading again the e-mails from Alex, it was not stipulated anywhere that a
re-org would trigger a new process of selecting the WDs. 

Cheers
   Vasile

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Friday, May 09, 2003 5:37 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: On BGP and VPLS

Hi Rick,

> Regarding the last part of your message, the working group chairs have 
> been asked to hold off of declarations of consensus on drafts in the 
> wake of discussions of re-organizing (ie. splitting) of the group.

What's the rationale for holding off declarations of consensus?  This
decision is two weeks overdue, and the split (if it happens) could take
several more weeks.

It would be a complete travesty if a simple consensus call took weeks but a
major decision like a split of the WG was completed in a hurry -- for one,
it would suggest that the split was preordained, and not a joint WG
decision, a point that Bilel was seeking clarification on.

Kireeti.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Mon, 12 May 2003 12:06:37 -0400

Yakov,

> 
> It should be abundantly obvious to an informed reader that use of
> BGP for autodiscovery (draft-ietf-ppvpn-bgpvpn-auto-03.txt), as
> well as for VPLS autodiscovery and label distribution utilizes
> exactly the same mechanisms as BGP/MPLS VPNs to support large-scale
> operation.
> 
> >  The above gives me a very uncomfortable feeling that the proposal
> >  is stretching BGP to perform functions it was not designed for.
> 
> IP wasn't designed to support CIDR.
> TCP wasn't designed to carrying routing information (BGP).
> RSVP wasn't designed to establish explicitly routed LSPs.
> etc...
> 

I add to it that LDP wasn't designed to signal MAC TLVs and to 
carry l2vpn related information...in fact the whole ietf
wasn't designed for sub-ip area (since it is considered temporary)!!

Hamid.

> And, bwt how do *you* know what BGP was designed for ? If one really
> wants to know what BGP was (and was not) designed for, then perhaps
> one should ask the folks who designed BGP.
> 
> Yakov.
> 
>