Subject: Draft-kpmpella-ppvpn-vpls-01

From: "Andrea Ferrarese" <[email-masked]>
Date: Tue, 22 Apr 2003 18:15:29 +0200

We support draft-kompella-ppvpn-vpls-01

We found that BGP control plane give scalability and flexibility. We
like
the possibility to maintain the actual config and VPN infrastructure
for
both l2 and l3 VPN.

Thank you

---

From: Ali Sajassi <[email-masked]>
Date: Tue, 22 Apr 2003 17:58:38 -0700

I'd like to know how many of the service providers who support this draft, 
only plan to offer multi-point Ethernet service (VPLS) and do NOT plan to 
offer point-to-point Ethernet service?

If a service provider plans to offer both types of services, then do they 
plan to use BGP for PW signaling of PtP Ethernet service ?

Thanks,
Ali

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Apr 2003 09:06:21 +0200

Hi Ali,

Very valid question ;) ... 

Even more valid would be to rephrase it to say: "Do all service
providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and
plan to offer some other forms of L2 p2p trasport would have objections
to run both signalling menthods for setting them up (BGP for VPLS and
targeted LDP for all other VPWS)" ? 

My personal _individual_ opinion is that vendors should support both
signalling options as it seems quite common that a proper and fine tuned
tool for any work produces better results :). 

Another spin on this thread is that if Juha's Radius propsal would be
selected as an auto-discovery option clearly there should be no need to
mess with BGP at all and signalling could be done with LDP in all cases.
But if one selects to use BGP for VPLS autodiscovery adding few more
bytes there with encoded very clever way of distributing label
informations especially for VPLS services seems very reasonable.

R.

> Ali Sajassi wrote:

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 23 Apr 2003 09:30:28 -0700

Hi Robert,

That was not the conclusion that I was arriving at. The way I look at it is 
if a service provider needs to support both type of services (Multipoint 
and PtP), then we know that BGP is not suited well for PtP applications; 
therefore, the service provider needs to support directed LDP (as specified 
in PWE3). Now if the service provider insists in using BGP as signaling 
mechanism for Multipoint application (VPLS), then they end up supporting 
and maintaining both types of signaling mechanisms in their networks !!

Also I don't like to tie up the signaling to the auto-discovery because 
they are independent. Therefore, a SP who wants to use BGP as 
auto-discovery, can do that and still use LDP as signaling and the SPs who 
want to use directory-based auto-discovery, can do that with the same LDP 
signaling.

The argument between BGP and LDP signaling is that the BGP-camp assumes 
that there is nothing else to be distributed to VPLS members except labels; 
whereas, LDP camp doesn't want to impose such a big constraint as there are 
PW characteristics (such as QoS, sequencing, OOB OAM) that require 
additional info exchanges. LDP signaling offers a more flexible approach to 
carry PW specific info and with the state of VPLS and data-plane still 
being evolved, I would like to have a flexible signaling. Besides, as 
mentioned before, you have to use the same signaling for PtP application 
anyway.

-Ali

---

From: Peter Schoenmaker <[email-masked]>
Date: Wed, 23 Apr 2003 09:56:06 -0700

> targeted LDP for all other VPWS)" ? 

As a service provider, i am looking at deploying both P2P services
and also P2MP services.  The ideal solution would allow me to provide
both types of services using the same toolset.  I want to minimize
the number of different ways we do things.  This improves our ability
to support the network.  I want to make things easier on the Network
operations people, and troubleshooting.

> tool for any work produces better results :). 

I would agree with this.  Different people have different needs.  
VPLS with BGP appears at this time to be an attractive solution 
for me.

I support draft-kompella-ppvpn-vpls-01

peter

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 23 Apr 2003 19:58:12 +0300

> mess with BGP at all and signalling could be done with LDP in all cases.

yes, there would be no need to mess with bgp, but actually no need to
mess with ldp either.  pure ip network is enough in my favorite
combination, which is radius/l2tpv3.  l2tpv3 has both signaling and data
plane built in into a single protocol.

-- juha

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 23 Apr 2003 13:34:31 -0700 (PDT)

Hi Ali,

> additional info exchanges.

I've seen this argument repeated many times, so let me respond.

Today, the PWs that make up a VPLS are point-to-point, i.e., each starts
at some PE and ends up on some other PE.  This is not a completely ideal
situation, as one would really like to use point-to-multipoint tunnels
for flooding -- but we don't (yet) have that technology in MPLS.  But
certainly for unicast, p2p PWs are fine.

But let's not confuse the fact that VPLS PWs are point-to-point with
the nature (p2p or p2mp) of signaling for those PWs.

The most basic function of signaling is the exchange of labels.  This
is inherently point-to-multipoint -- all other PEs in a VPLS need to
know what labels to use to send packets to the signaling PE.

The next function of signaling is the withdrawal of labels, either
because of administrative intervention or because the PE-CE link went
down.  Again, this is point-to-multipoint -- all other PEs in the VPLS
need to be told.

Another thing that needs to be communicated, be it during discovery or
during signaling, is the MTU on the PE-CE interfaces.  Again, this is
point-to-multipoint -- the same value is sent to all peers.  (BTW, to
correct your statement above, BGP does signal MTU, not just labels.)

Another signaling function described in draft-lasserre-vkompella-ppvpn-vpls
is MAC Address Withdrawal.  Again, this is point-to-multipoint -- a PE
uses this to inform all other PEs in the VPLS to remove a certain set
of MAC addresses from their filter tables.

So, what aspect of signaling is inherently point-to-point?  I.e., what
information might one want to signal to some (but not all) members of a
VPLS?  Let's take your examples:

> (such as QoS, sequencing, OOB OAM)

1. QoS is a nice, broad term.  To some, it means bandwidth settings
   (CIR, burst, etc.); to others it means setting DSCPs or EXP bits.
   Let's take these in turn.

a) bandwidth (CIR, burst, ...): For VPLS (as for IP, i.e., for any-to-any
   services), the most natural b/w expression is the "hose model",
   where the PE-CE connection is limited to (say) 2M CIR and 8M burst.

   Even if a detailed traffic matrix ("pipe model") were desirable (for
   VPLS and for IP), i.e., site 1 can send 2M to site 2, 6M to site 3,
   etc., is there a need to signal this info?  This is simply implemented
   locally at each PE.

   If one goes down this path -- "we want a detailed traffic matrix, and
   we have to signal this" -- does one then abandon BGP signaling for IP
   VPNs and switch to LDP signaling?

   If on the other hand, one decides to go with the hose model, one
   could very well use the bandwidth community for VPLS as well as for
   RFC 2547 IP VPNs.

b) DSCP/EXP setting -- this is again simply done locally, and in the
   fortunate case of VLANs, there could be a straightforward mapping of
   .1p bits to DSCP/EXP.  Again, this mapping would be the same across
   the VPLS (otherwise, one would have a management nightmare).  Thus,
   even if this was signaled, the signaling would be point-to-multipoint.

2. Sequencing.  It seems to me that for a given VPLS, one either does
   sequencing among all the PEs for this VPLS, or not.  The situation
   where one does sequencing among some but not others seems excessively
   complex.  In any case, sequencing is done in the data plane -- a
   sequence number of 0 means no sequencing; non-zero means do sequencing.

3. OOB OAM.  Not sure what this means: what is to be signalled, and what
   makes it point-to-point (i.e., PE1 wants to tell PE2 but not PE3)?
   Could you elaborate?

My conclusion (so far; I will wait for your/Eric's responses) is that
VPLS signaling is basically point-to-multipoint.  That is bolstered by
the fact that the LDP signaling defined in lasserre-vkompella doesn't
actually have any parameters that are useful to signal to one PE in the
VPLS but not any other.

In the light of this conclusion, it seems much more natural to use a
point-to-multipoint signaling mechanism (BGP) for VPLS rather than a
point-to-point mechanism (LDP).

Kireeti.

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 23 Apr 2003 15:06:10 -0700

Kireeti,

See below.

-Vach

> know what labels to use to send packets to the signaling PE.

Which is a pt-2-pt function.  The fact that you are using a multi-point approach
does not actually reflect that what you are doing is pt-2-pt (since the labels
are signaled pt2pt, despite the label ranges).

This is quite unlike the *true* pt-2-multipoint nature of, say, a route
advertisement in IPv4, where everyone uses that route (modulo IGP costs, etc.),
or VPN-IPv4 route advertisements, which all participating PEs use identically.

Or, as you pointed out, the MTU, which it would be nice (but not essential) to
send pt-2-multipoint to all PEs in a VPLS.

> point-to-point mechanism (LDP).

BGP, to be precise, is not a pt-2-multipoint; it is a broadcast mechanism.  That
is the issue.  At what size VPN does a broadcast mechanism start becoming a
useful tool?  Just because you have a route reflector (one common answer given
for this issue), you don't reduce the number of BGP messages being sent.

BGP policies is another answer I saw: the filtering of messages at each PE
doesn't reduce the number of messages sent.  Tailoring the policy to cover the
PEs in a VPN also doesn't quite cut it because you lose the auto-discovery since
the membership is essentially encoded into the policy.

So here's an example of an extension that would really work better with pt2pt
signaling.  Suppose we have a router that is not capable of tag manipulation.
Martini extensions for signaling the desired tag value are described for the
VLAN VC type.  It would be possible to use that on a per-PW basis.  Then we
wouldn't require the VPLS tag manipulation capability.  If you have that
capability, as Ali pointed out in some other context, there are ways then to
distribute the VPLS function across the PE and a bridge behind it.  (Perhaps Ali
will draw that picture; ascii art and multi-site VPNs don't go well together).

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 23 Apr 2003 15:48:47 -0700

Hi Kireeti,

Even though my original email was intended to find out what the SPs plan to 
do for P2P applications (e.g. VPWS) considering that it is based on Martini 
signaling and whether they want to have two types of signaling for L2VPN 
applications (e.g., one for VPWS and other for VPLS) considering that they 
say they want to leverage the same "tools" across different applications, 
you have focused in here on the applicability of BGP to VPLS application 
only. That's fine and lets go over it.

>certainly for unicast, p2p PWs are fine.

There are some VPLS proposal that use MP2P PWs for unicast but these 
proposals have some other issues. So P2P PWs for unicast is not the only 
approach but it is the one that got used in the original draft-lasserre and 
you are using it in your draft as well.

>VPLS?  Let's take your examples:

Yes, we are having the same discussion as before and it comes down to 
whether there are PW specific info to be exchanged. So lets take a closer look.

>    even if this was signaled, the signaling would be point-to-multipoint.

When we talk about the QoS SLA, there are two aspects of it, one at the 
customer UNI and the other at the topology level (e.g., links among 
customer sites). With respect to the examples of QoS that you have 
provided, they are relevant to customer UNI and they don't address the 
topology side of it. To better understand what I mean by topology, let me 
give you an example. For the sake of this discussion, a VPLS instance for a 
given customer can be modeled by a set of Virtual switches connected with 
each other via PW links. Similar to the LAN network which is important for 
the customer to choose link BW and quality appropriately among different 
switches/bridges, it can be as important for the customer in doing the same 
thing for the PWs so that in case of congestion in the core, they are 
guaranteed with certain BW (either aggregate or on a per class basis). I 
have received such requirements from some customers although I don't think 
this would be the norm but nonetheless there will be some and we need to 
support it . So given that you want to setup BW and QoS on a per PW basis, 
then this is PW specific info that needs to be exchanged between two 
end-points and not everyone else.

>    sequence number of 0 means no sequencing; non-zero means do sequencing.

Why not. Given that sequencing introduces additional overhead, the SP might 
want to be able to offer this at the lower granularity level (e.g., per 
pair of customer sites) rather than per VPLS instance. Also customer may 
want this service between two of its major hubs instead of among all the sites.

>    makes it point-to-point (i.e., PE1 wants to tell PE2 but not PE3)?

I meant OAM based on out-of-band - e.g., using signaling to check the PW 
status. As you have noticed there are some discussion on the list to 
control the status of the emulated VLAN (e.g., the set of PWs) based on the 
status of one of them. So one needs to be able to check the health of each 
PWs individually and having an out-of-band mechanism provides additional 
option. Also VCCV (which provides an OAM ping for PW) is based on LDP.

>actually have any parameters that are useful to signal to one PE in the

Not everything has been addressed by the draft-lasserre-vkompella at this 
point but does it mean we should paints ourselves in the corner.

-Ali

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 23 Apr 2003 16:24:32 -0700 (PDT)

Ali Sajassi writes:

> When we talk about the QoS SLA, there are two aspects of it, one at
> the customer UNI and the other at the topology level (e.g., links
> among customer sites). With respect to the examples of QoS that you
> have provided, they are relevant to customer UNI and they don't
> address the topology side of it. To better understand what I mean by
> topology, let me give you an example. For the sake of this
> discussion, a VPLS instance for a given customer can be modeled by a
> set of Virtual switches connected with each other via PW
> links. Similar to the LAN network which is important for the
> customer to choose link BW and quality appropriately among different
> switches/bridges, it can be as important for the customer in doing
> the same thing for the PWs so that in case of congestion in the
> core, they are guaranteed with certain BW (either aggregate or on a
> per class basis). I have received such requirements from some
> customers although I don't think this would be the norm but
> nonetheless there will be some and we need to support it . So given
> that you want to setup BW and QoS on a per PW basis, then this is PW
> specific info that needs to be exchanged between two end-points and
> not everyone else.

I'm not sure i'm being able to parse your statement correctly... I'm
assuming that you require the L2 service to be mapped to several
different classes of service that the SP provides.

The way this is implemented today (for 2547 or BGP-based L2VPN or VPLS) is:

- You have "blue"/"red"/"green" RSVP LSPs between PEs.
- Community tag on the corresponding BGP route selects which color LSP
to use.

This is deployed by more than one SP for 2547... it works AFAIK.

Just another example why some people find it attractive to be able to
use the same model L3VPNs and L2VPNs... a fair ammount of problems
have been solved w/ L3VPNs that are also applicable to L2.

IMHO, a deployable service has to include issues such as: inter-as
operation, QoS mapping, auto-discovery, etc...

  Pedro.

---

From: Quaizar Vohra <[email-masked]>
Date: Wed, 23 Apr 2003 17:16:56 -0700 (PDT)

Ali,

It seems that the argument for LDP signalling here is that it is
flexible enough to allow for signalling of many a bells and whistles
on a P2P basis. But if these bells and whistles are deduced from
configuration then you end up loosing the benefits of autodiscovery.

Autodiscovery followed by P2P signalling is beneficial if all the
stuff signalled on a P2P basis is deduced interrnally within the
protocol or if there is some inherent protocol behavior which
is p2p in nature then I can see the usefulness of P2P signalling.

Quaizar

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 24 Apr 2003 10:51:01 -0400

>the membership is essentially encoded into the policy.

         You also left out the fact that crafting these policies is not
always such a trivial effort.

         --Tom

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Apr 2003 17:09:38 +0200

> always such a trivial effort.

Well if we are into left out points sure RR does not reduce the number
of BGP mesages send nor does filtering at each PE do so. 

But BGP mechanism like extended community ORF (or similar approaches
based on policy propagation see draft-marques-ppvpn-rt-constrain-00.txt
as a possible indication of more then peer to peer policy propagation)
achive the very point of both above paragraphs at a per RT granularity
quite well ;-).

R.

---

From: "Mike Duckett \(Dotnet\)" <[email-masked]>
Date: Thu, 24 Apr 2003 11:44:31 -0400

Ali,

I think the WG goal is to move forward with a reduced set of proposals.
Otherwise, efforts are diluted, costs are higher, interoperability issues
abound, and the ability to impact the market is impaired.  Reducing
proposals requires evaluation of options and considering deficits.
Therefore, corners will be considered.

----- Original Message -----
From: "Ali Sajassi" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 23, 2003 6:48 PM
Subject: Re: Draft-kpmpella-ppvpn-vpls-01

[snip]

---

From: "Jim Guichard" <[email-masked]>
Date: Thu, 24 Apr 2003 12:00:34 -0400

yes, but why introduce all this machinery for L2 PW when you can just send
it directly to the relevant peer using existing PWE3 defined mechanisms ? I
think the other point that Tom was making is that maintenance of the
filtering is not trivial even with tools such as ORF. Jim

> >-----Original Message-----
> >From: Robert Raszuk [mailto:[email-masked]]
> >Sent: Thursday, April 24, 2003 11:10 AM
> >To: Thomas D. Nadeau
> >Cc: [email-masked]; Kireeti Kompella; [email-masked];
> >[email-masked]; [email-masked]
> >> >PEs in a VPN also doesn't quite cut it because you lose the
> >auto-discovery
> >> >since

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Apr 2003 18:31:11 +0200

Well from my personal observations the dispute to use BGP or directed
LDP for VPLS service can go on for months :). What I think we as ppvpn
group should be looking at is a signaling protocol for VPLS aplication
as such which could work for any transport ... p2p MPLS, p2mp MPLS,
L2TPv3, realiable multicast etc .... 

Selection of signalling by all means should not be associated with
auto-discovery by design. I think we all agree with this one. Although
pushing forward only one signalling approach being now p2p MPLS very
tightly associated with the transport seems IMHO not too future oriented
vision. I think if we would have had deployed some other then BGP
generalized flooding protocol kompella-vpls would use it. For the lack
of it and presence of BGP commonly used the authors choice was clear. 

The reason I do have some sympathy to this approach is that today the
trick/hack/clever design is to use a formula and calculate the label by
reciever not by senders, tomorrow it could be extended to distribute
L2TPv3 parameters or some multicast keys. Hopefully VPLS service in WANs
will die soon but if not does the replication on ingress to SP core (for
broadcast/multicats) is the best of flat ethernet distributions strategy
which would be done for years to come ?

On the other hand I fully support that for p2p L2 transport services p2p
signalling should be a clear choice - today being directed LDP or
L2TPv3.

R.

> Jim Guichard wrote:

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 24 Apr 2003 14:08:12 -0400

>filtering is not trivial even with tools such as ORF. Jim

         Precisely my point.

         --Tom

---

From: Eric Rosen <[email-masked]>
Date: Thu, 24 Apr 2003 14:57:41 -0400

Kireeti> The most basic function of signaling is the exchange of labels.  This
Kireeti> is inherently point-to-multipoint -- all other PEs in a VPLS need to
Kireeti> know what labels to use to send packets to the signaling PE.

Well, if you owe $1.00 to each of 100 people, you owe $100, but you wouldn't
send each one a $100 bill.  Or would you? ;-)

When a new PE, PE A, joins the VPLS, it must assign a label to each of the other
PEs.  PE A must  distribute, to each of the other PEs,  the label that A has
assigned **to that particular PE**. 

Since a different  label must be distributed to each of  the other PEs, this
signaling is inherently point-to-point, not point-to-multipoint. 

Further, each of  the other PEs now has  to assign a label for PE  A to use,
and  distribute that label  to PE  A.  Again,  this is  inherently point-to-
point.  No  other PE needs  to send  any labels to  anyone other than  PE A.
Certainly  we don't  want PE  B telling  PE C,  "just for  your information,
here's the label I'm giving to PE A".

Point-to-multipoint signaling would be required  if PE A sent the same label
to each of the other PEs, i.e., if the pseudowires were multipoint-to- point
(as in IPLS).   But you can't do VPLS  with multipoint-to-point PWs, because
there would be no way to do the MAC learning.

By  the way,  if you  agree that  BGP signaling  only makes  sense  when the
signaling  operations  are inherently  point-to-multipoint,  perhaps we  can
dispense now with any proposal to use BGP signaling for VPWS!

Kireeti> The next function of signaling is the withdrawal of labels, either
Kireeti> because of administrative intervention or because the PE-CE link went
Kireeti> down.  Again, this is point-to-multipoint -- all other PEs in the VPLS
Kireeti> need to be told. 

Well, yes, each PE  needs to be told something, but each  needs to be told a
different thing, since each is using a different label. 

Kireeti> Another thing that needs to be communicated, be it during discovery or
Kireeti> during signaling, is the MTU on the PE-CE interfaces.  Again, this is
Kireeti> point-to-multipoint -- the same value is sent to all peers.

Here I agree; MTU must be the same on all interfaces, and is not a parameter
that changes during normal operation.  Communicating the MTU can be regarded
as part of the auto-discovery, and it's okay to handle it via BGP.  

Kireeti> 2. Sequencing.  It seems to me that for a given VPLS, one either does
Kireeti>    sequencing among all the PEs for this VPLS, or not.  The situation
Kireeti>    where one does sequencing among some but not others seems excessively
Kireeti>    complex.  In any case, sequencing is done in the data plane -- a
Kireeti>    sequence  number of  0 means  no sequencing;  non-zero  means do
Kireeti>    sequencing. 

In order to do  sequencing, when a pseudowire first comes up,  PE A needs to
tell PE B  which sequence number it  is expecting.  At any given  time, PE A
will expect  the next packet  from PE B  to have one sequence  number, while
expecting the  next packet from  PE C to  have a different  sequence number.
This  notion of  "next  expected sequence  number"  is inherently  point-to-
point. 

Further,  at  any given  time,  PE  A and  PE  B  may  lose sequence  number
synchronization (a sequence of packets  whose sequence numbers are more than
half the sequence  space away from the next  expected sequence number should
probably be taken as loss of synchronization) their pseudowire, and may need
to resynchronize, with A telling B what sequence number to reset to.

There are two possible ways to do the sequence number synchronization: 

1.  Explicit point-to-point  handshake  when a  pseudowire  starts, or  when
   resynch is required.  Well, you couldn't do this effectively with BGP. 

2.  When a  label  is first  received,  start with  sequence  number 1.   To
   resynchronize, withdraw  the label,  and then assign  a new (or  the same
   label) to indicate  that the next expected sequence  number is once again
   to be 1.  (Actually, this doesn't seem  so good, as you might not want to
   always restart with 1, but we'll ignore that for now.)

   a.  If  you withdraw  a  label, and  then  reassign the  same label,  BGP
       signaling is  not guaranteed to  convey the withdrawal to  the remote
       PE.

  b. You could  withdraw the label and assign a different  label, but then I
     think you've given up any hope of using label blocks. 

  c. You could withdraw the label and reassign the same label, but with some
     different  attributes.  Presumably for  each remote  PE, there'd  be an
     attribute  which specifies  the starting  sequence number.   (Again, so
     much for label  blocks.)  And now it's not much  different than 1; when
     PEs A and B  have to resynch sequence numbers, all the  other PEs get a
     message as well.) 

Kireeti>    Even if a detailed traffic matrix ("pipe model") were desirable (for
Kireeti>    VPLS and for IP), i.e., site 1 can send 2M to site 2, 6M to site 3,
Kireeti>    etc., is there a need to signal this info?  This is simply implemented
Kireeti>    locally at each PE. 

While there's no  question that the hose model is more  scalable, there is a
place for the pipe model, even in L3VPN.  But I think it will be more widely
applicable to L2VPN, because "pipe" is really an L2 concept.

Kireeti> is there a need to signal this info?  This is simply implemented
Kireeti>  locally at each PE. 

Then you need  to explicitly configure it on both  ends; with signaling, you
can configure  it on one end  and signal it  to the other.  Same  applies to
DSCP/EXP bit settings,  and I don't see why those  would necessarily want to
be the  same for  all site  pairs.  This would  also be  very useful  if you
wanted to  make QoS  changes dynamically,  based on time  of day  or network
conditions or whatever. 

In  fact, people have  asked to  be able  to use  RSVP-TE as  the pseudowire
signaling  protocol, to  help unify  the QoS  signaling with  the pseudowire
signaling.  (Though I'm certainly not advocating that.)

A closely related  issue, of course, is congestion  control.  It's been made
pretty clear that the IESG expects to see some congestion control mechanisms
for pseudowires.   Neither PWE3  nor PPVPN has  paid much attention  as yet.
But this  is likely to  require some kind  of reliable feedback  between the
endpoints of  a pseudowire.  For example,  the endpoints might want  to do a
periodic exchange of "packets received on this pseudowire", "packets sent on
this pseudowire" statistics, so they can tell whether packets are being lost
in the network.  That's just an example, I don't know if the ultimate scheme
will be like that.   But there does seem to be a  need for some mechanism by
which  one endpoint  can tell  the  other "slow  down".  This  seems like  a
point-to-point interaction, not a point-to-multipoint interaction.

Kireeti>    If one goes down this path -- "we want a detailed traffic matrix, and
Kireeti>    we have to signal this" -- does one then abandon BGP signaling for IP
Kireeti>    VPNs and switch to LDP signaling? 

Well, that wouldn't do much good unless  you can figure out a way to use LDP
to  distribute routing.  And  it still  wouldn't do  much good,  because the
L3VPN  transport  mechanisms are  entirely  multipoint-to-point; there's  no
point-to-point or point-to-multipoint stuff at all.  Well, the pipe model is
not nearly as good a fit to L3VPN as it is to L2VPN.

Kireeti> 3. OOB OAM.  Not sure what this means: what is to be signalled, and what
Kireeti>    makes it point-to-point (i.e., PE1 wants to tell PE2 but not PE3)?
Kireeti>    Could you elaborate?

See my congestion control example above. 

Another example.  A problem in the  data plane is detected, and one wants to
try "resetting" the pseudowire, to see  if tearing it down and setting it up
again gets around the problem.   Naturally, one would prefer that both sides
use different  labels for the  restored pseudowire, in  case one end  or the
other is having  some problem with a particular label.   This is easily done
with a point-to-point signaling mechanism. 

OAM problems are almost always point-to-point problems. 

I agree  that signaling  status of external  interfaces is NOT  relevant for
VPLS, though of course it would be for VPWS.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 24 Apr 2003 15:26:27 -0400

Quaizar> It seems that the argument for LDP signalling here is that it is
Quaizar> flexible enough to allow for signalling of many a bells and whistles
Quaizar> on a P2P basis. But if these bells and whistles are deduced from
Quaizar> configuration then you end up loosing the benefits of autodiscovery.

It is  true that the more you  need to configure on  a point-to-point basis,
the less  benefit you  get from auto-discovery.   However, we don't  have to
choose one extreme or  the other; I think it's best to  provide for both and
allow the provider to use the mix that best suits his needs. 

One of  the perennial issues faced when  designing auto-discovery procedures
is that as  time goes on, we  keep figuring out more and  more properties of
the endpoints  that need  to be auto-discovered,  with a consequent  need to
keep extending  the auto-discovery mechanisms.   One school of  thought says
that auto-discovery ought  therefore to be minimal, telling  you only who to
connect to; then  once you connect, you use  signaling to discovery whatever
else needs  to be known before  you can start operation.   Another school of
thought  says  that  you  should  just  keep  extending  the  auto-discovery
procedures  as needed.   The  best  practice is  probably  somewhere in  the
middle.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 24 Apr 2003 15:25:09 -0400

>    resynch is required.  Well, you couldn't do this effectively with BGP.

         Right, which is easy to do with a protocol designed to be P2P.

>      PEs A and B  have to resynch sequence numbers, all the  other PEs get a

         But isn't withdrawing the label going to be potentially disruptive?

         --Tom

---

From: Wei Luo <[email-masked]>
Date: Thu, 24 Apr 2003 15:25:09 -0700

> know what labels to use to send packets to the signaling PE.

Only when the signaling PE wants all other PEs to use the same label, this type
of point-to-multipoint signaling makes sense.  Put in a different way, if the
signaling PE wants to assign a different label to a different PE, there is no
reason to tell all other PEs the labels they don't even use.

But for VPLS, the signaling PE can not really assign the same label for all
other PEs, because you will not be able to associate source MAC addresses with
any particular PE based on the label.  Therefore, you will not be able to
perform any MAC address learning.  I hope you did not suggest to flood all
packets at all occasions for VPLS.

> down.  Again, this is point-to-multipoint -- all other PEs in the VPLS

The same applies to withdrawal.

---Wei