Re: [mpls] MPLS-RT review of draft-jin-jounay-mpls-mldp-hsmp

[Lizhong Jin<[e-mail]>]

Hi Thomas,
Thank you for this review. Please see inline below.

Regards
Lizhong


Thomas Morin <[e-mail]> wrote 2012/07/20 22:37:06:

> Hi,
> 
> [please ignore my previous mail, sent before it was ready; my apologies]
> 
> I've reviewed this draft and here is my attempt at commenting on the
> different aspects as expected for this review.
> 
> What the specs aim to achieve and the procedures described seem to me
> as technically sound.
> 
> I am however, not convinced by all the use cases put forward in section
> 2. 
> 
> The first one is time synchronisation, but there is no detailed
> explanation of why having a leaf-to-root path is needed ("PTP slave
> might have to send also messages") nor why having this path be
> co-routed is a benefit. 
[Lizhong] time synchronization [IEEE1588] requires the sync packet from 
master to slave to be co-routed with the delay request packet from slave 
to master. We will add these detail according IEEE1588 in the next 
version.

> 
> The second one is IPTV ; one thing that bothers me is that with only
> one router as the root, it seems that it will be very hard to implement
> redundancy of the IGMP Querier function and source-side router and. 
[Lizhong] If redundancy root node is required, two HSMP LSP could be 
provided. Section 6 has some considerations about redundancy.

> 
> The third application case is L2VPN, with a key claim being a reduced
> operational cost due to having less LDP state in the network. For VPLS,
> I don't understand where the gain is supposed to come from, compared to
> the solution used in draft-ietf-l2vpn-vpls-mcast and
> draft-ietf-l2vpn-evpn.
[Lizhong] In this application, the PSN tunnel operational cost is reduced 
by HSMP LSP, you do not need to setup P2MP LSP + P2P LSP on each PE, but 
use HSMP LSP instead. VPLS-MCAST and EVPN does not talk about PSN tunnel 
operational cost. Actually HSMP LSP could be also applied in VPLS-MCAST 
and EVPN. We will make this part to be more clear to avoid 
misunderstanding.

> 
> So, I would say that the draft is in a good shape for being considered
> for adoption. In my own view, the use cases would need to be more
> strongly backed and/or more detailed (and if necessary, the claims of
> applicability reduced) but discussing this is a natural part of a
> debate on adoption.
> 
> Thanks,
> 
> -Thomas
> 
> 
> 
> 2012-07-12, Ross Callon:
> > Thomas, Ravi, Mach;
> > 
> > You have been selected as an MPLS Review team reviewers for
> > draft-jin-jounay-mpls-mldp-hsmp
> > 
> > Note to authors: You have been CC’d on this email so that you can
> > know that this review is going on. However, please do not review your
> > own document. 
> > Reviews should comment on whether the document is coherent, is it
> > useful (ie, is it likely to be actually useful in operational
> > networks), and is the document technically sound?  We are interested
> > in knowing whether the document is ready to be considered for WG
> > adoption (ie, it doesn’t have to be perfect at this point, but should
> > be a good start). 
> > Reviews should be sent to the document authors, WG co-chairs and
> > secretary, and CC’d to the MPLS WG email list. If necessary, comments
> > may be sent privately to only the WG chairs.
> > 
> > Are you able to review this draft by July 27, 2012 (ie, prior to the
> > IETF meeting in Vancouver)?
> > 
> > Thanks, Ross
> > (as MPLS WG chair)
> > 
>