Subject: RE: p2mp PWs (was RSVP-TE and PW)

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 5 Oct 2004 15:34:50 -0700 (PDT)

Hi Peter,

On Tue, 5 Oct 2004, Busschbach, Peter B (Peter) wrote:

> Diego, Eric,
>
> Regarding p2mp PWs:
>
> There are concerns that in VPLS or HVPLS solutions, the number of MAC entries in the (N-)PE could become excessively large. Therefore, it could make sense to move to a DVPLS model (as described in draft-ietf-l2vpn-signaling-02.txt, section 3.5).
>
> In this model, the link between U-PE and N-PE carries all PWs that originate in the U-PE. Therefore, multicast or broadcast packets would be replicated multiple times on the same link. However, since the link may have limited bandwidth, this replication of identical packets might cause concerns. Hence, it could make sense to have some form of p2mp PWs, where the N-PE splits the traffic coming from the U-PE onto multiple branches.
>
> Note that the GVPLS solution (draft-radoaca-ppvpn-gvpls-02.txt (I couldn't find a newer draft)) supports such a broadcast/multicast feature. This is not a true example of p2mp PWs, but it illustrates the idea.
>

Also see the VPLS multicast solution in the following draft. In principle
the solution builds P2MP PWs for VPLS.

http://www.ietf.org/internet-drafts/draft-raggarwa-l3vpn-mvpn-vpls-mcast-00.txt

rahul

> Peter
>
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[email-masked]]
> > Sent: Tuesday, October 05, 2004 12:04 PM
> > To: [email-masked]
> > Cc: pwe3
> > Subject: Re: [PWE3] RSVP-TE and PW
> >
> >
> >
> > Hi Eric,
> >                  first of all let me say thanks to  you and to all the
> > other guys involved in thuis thread, as I said in my first e-mail I'm
> > pretty new to this stuff.
> >
> > Other stuff in-line.
> >
> > Diego
> >
> >
> >
> > Eric Rosen <[email-masked]> on 05/10/2004 16.50.25
> >
> > Please respond to [email-masked]
> >
> > To:    "Diego Caviglia" <[email-masked]>
> > cc:    [email-masked]
> >
> > Subject:    Re: [PWE3] RSVP-TE and PW
> >
> >
> >
> > This thread  is getting  a bit  repetitive, I'll try  to
> > avoid  repeating
> > my
> > opinions on issues  that I've already tried to address.
> > Diego raises a
> > new
> > issue though:
> >
> > > LDP doesn't have mp2p
> >
> > Did you mean p2mp?
> > [dc] Yes it was a typo.
> >
> > In  either case,  it's far  from clear  what a  multipoint PW
> >  would  be,
> > we
> > haven't  actually defined  any such  concept.   (The PWs
> > we've defined
> > are
> > bidirectional.)
> > [dc] Ok so you think that p2mp (and unidirectional PW) could
> > be something
> > that will be addressed by PWE3 WG in the future?
> >
> >
> > The closest  thing to  a p2mp  PW that we  have is  the VPLS  service,
> > which
> > already has  two non-interoperable signaling protocols  and probably
> > doesn't
> > need a third.
> > [dc] Yes but in VPLS you have to split traffic at the PE that
> > may be is not
> > the best place to do that.
> >
> > Without more  discussion of just what a  multipoint PW is,
> > it's  hard to
> > say
> > whether we need to have such things, or just what the
> > signaling protocol
> > for
> > it should be.
> > [dc] I agree I was trying to understand if it something
> > interested in p2mp
> > PW.
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Eric Rosen <[email-masked]>
Date: Tue, 05 Oct 2004 21:55:49 -0400

> the solution builds P2MP PWs for VPLS. 

And it does it without requiring the use of RSVP-TE ;-)

Actually, all  that it does is  provide a way to  use multicast distribution
trees to  carry IP  multicast packets.  The  receiving PEs then  process the
packets  as  if  the  packets  had  arrived  on  the  unicast  PW  from  the
transmitting PE.   I don't think that's  quite the same as  a multipoint PW.
(If you try to model the multicast distribution tree as a PW itself, you end
up  with   a  pair   of  ethernet  switches   connected  by   two  different
(pseudo)wires, with both of them unblocked -- I don't think there's any such
entity.)

The closest  thing we have  to a multipoint  PW is the VPLS  service itself,
which is  designed to produce  the properties of  a multipoint-to-multipoint
wire. 

Is  there   actually  a  layer  2  service   which  provides  unidirectional
point-to-multipoint transmission?  If we knew  what we needed to do in order
to emulate such a service, we'd know what the signaling requirements are for
p2mp PWs.

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 6 Oct 2004 00:38:16 -0700 (PDT)

Hi Eric,

On Tue, 5 Oct 2004, Eric Rosen wrote:

> trees to  carry IP  multicast packets.

And the same SP tree can carry IP multicast packets belonging to multiple
VPLS instances. This is analogous to the same transport tunnel carrying
packets for multiple L2 circuits.

> The  receiving PEs then  process the
> transmitting PE.

Not quite. The IP multicast packet carries an upstream label which is a
different label from the one used by the unicast PW. The upstream label is in the context
of the sender PE and assigned by the sender PE, while the unicast PW label
is assigned by the receiver PE.

> I don't think that's  quite the same as  a multipoint PW.

Maybe its a matter of terminology. The above draft allows one multicast distribution
tree to be used for carrying IP multicast packet from multiple VPLS
instances. And I thought part of the discussion on this thread had to do
with being able to achieve such a function. The term P2MP PW was used to
describe such a function, though that may not be the best terminology.

Thanks,
rahul

---

From: Eric Rosen <[email-masked]>
Date: Wed, 06 Oct 2004 12:32:14 -0400

Eric> The  receiving PEs  then process  the packets  as if  the  packets had
Eric> arrived on the unicast PW from the transmitting PE.

Rahul> Not quite.  The  IP multicast packet carries an  upstream label which
Rahul> is  a different  label from  the  one used  by the  unicast PW.   The
Rahul> upstream label is in the context of the sender PE and assigned by the
Rahul> sender PE,  while the  unicast PW label  is assigned by  the receiver
Rahul> PE. 

The "processing" I was referring to  was the processing of the packet by the
"ethernet switch"  after the packet is decapsulated.   What you're referring
to above is  the "MPLS decapsulate and dispatch" function.   What you say is
correct, but I think not in conflict with what I said (or meant to have said
:-)). 

If the multicast distribution tree were  to be treated as an independent PW,
then we'd end up  with two PWs between a pair of  bridges.  Would we need to
send the BPDUs on both of them?   Should one of the PWs be in blocking state
if the other  is active?  When we  do MAC learning, do we  associate the MAC
SAs learned from multicast packets with the multicast tree, rather than with
the unicast PW?

In your proposal, I think you really don't want the ethernet bridge function
to  know whether a  received packet  came from  the unicast  PW or  from the
multicast  distribution tree, though  of course  the MPLS  decapsulation and
dispatch function needs to know this.  That's why I don't really regard your
proposal as  creating a multicast PW.   That's just meant  as an observation
about your proposal, not as a criticism of it.