Hi Lizhong, Edward,
It seems that it is a good idea to apply HSMP LSP to VPLS, and the
broadcast/unicast/unknow packet would be optimized. However, the path from
leaf to root may not be the best path compared with current VPLS using P2P
LSP, which is not a critical issue.

Thanks
Lamberto



>
> ------------------------------
>
> Date: Wed, 5 Jan 2011 15:50:45 +0800
> From: [email protected]
> Subject: Re: [mpls] Request comments for HSMP LSP
> To: Ed <[email protected]>
> Cc: [email protected], [email protected], Ice <[email protected]>,
>        [email protected],   [email protected]
> Message-ID:
>        <
> of4ba0bf75.a883e04c-on4825780f.002802e4-4825780f.002b2...@zte.com.cn>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Edward,
> Thank you for the comments. I add l2vpn maillist in cc list. I agree with
> the application you proposed, and in order to improve the scalability of
> VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually
> this is a good application case for P2MP PW with reverse path (section
> 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this
> use case.
>
> Regards
> Lizhong
>
>
> Ed <[email protected]> wrote on 2011-01-05 15:05:30:
>
> > Hi Lizhong,
> >
> > I think one possible application for HSMP LSPs is to reduce the
> > overall broadcast/multicast utilization on a VPLS. In current VPLS
> > implementations with a full mesh of P2P LSPs between PEs, broadcast,
> > multicast and unknown traffic are not efficiently propagated on the
> > physical links between PEs and Ps.
> >
> > In the VPLS implementation scenario with HSMP LSPs, each PE signals
> > a HSMP LSP with itself as a root to all other PEs in the VPLS.
> > Thereafter, all broadcast/multicast/unknown traffic from this PE
> > will use this HSMP LSP. Unicast traffic from a particular PE (e.g.
> > PE1) to another PE (e.g. PE2) will be sent from leaf to root using
> > the HSMP LSP where PE2 is the root.
> >
> > This simplifies the VPLS implementation by:
> > -          Reducing traffic utilization from broadcast, multicast
> > and unknown traffic
> > -          Reducing the total number of LSPs maintained by each PE
> > (i.e. instead of requiring a full mesh of LSPs, now only require one
> > HSMP LSP per PE).
> >
> > This is similar to the idea expressed in  draft-key-l2vpn-etree-
> > frwk-03.txt (in a more general sense).
> >
> > What do you think? Would HSMP LSP be suitable for this?
> >
> > Regards,
> > Edward
> >
> >
> >
> > On Wed, Jan 5, 2011 at 5:24 PM, <[email protected]> wrote:
> >
> > Hi all,
> > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS
> session.
> > HSMP LSP has several use cases described in the draft, e.g, time
> > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would
> > be appreciated if you could give more scenarios for HSMP LSP. Please
> > review the draft, and any comments are welcome.
> >
> > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-
> > mldp-hsmp-01
> >
> > Thank you.
> > Authors of draft-hsmp.
> > --------------------------------------------------------
> >
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc

Reply via email to