Subject: Re: [mpls] draft-jin-jounay-mpls-mldp-hsmp

From: Lizhong Jin<[email-masked]>
Date: Tue, 31 Jul 2012 10:03:34 +0800

> > Hi Lizhong,
> > 
> > Lizhong Jin :
> > > 
> > > 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. 
> > 
> > Note that it still does not allow proper IGMP fallback in case of 
> > Querier failure, because the two Queriers won't see each other; it's
> > also unclear to me how you would ensure both that the two queriers 
> > have proper IGMP state and that you don't have packet duplication.
> [Lizhong] Sorry, I did not describe this clear. If the root is the 
> IGMP Querier and source-side router, you are right, it is hard to 
> provide redundancy. The two HSMP LSP redundancy scenario would be 
> valid when the IGMP Querier router acts as a client for both HSMP 
> LSP, and multi-home to the two root nodes of HSMP LSP. This is still
> not IGMP Querier router node redundancy, but HSMP LSP redundancy. In
> that case, the IGMP Querier router node redundancy could be 
> implemented by other mechanism, and independent of HSMP LSP 
> redundancy. Note that the root node of HSMP LSP is not necessary to 
> be IGMP Querier router in IPTV scenario.
[Lizhong] note that if root node is not IGMP Querier router, VPMS 
multiplexed to HSMP LSP should be used to trasmit IGMP in above case, not 
IGMP over HSMP LSP. We will add the redundancy limitation to the draft.

Thanks
Lizhong

> 
> > > 
> > > 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.
> > 
> > Basically, for *each* P2MP LSP (eg. one per-PE per VPN) your 
> > proposal adds a (co-routed) path back to each PE, but this offer no 
> > gain of state on P-routers, since in a typical scenario unicast LDP 
> > is already here, and even assuming it is not, the cost of adding it 
> > is minimal and (contrary to HSMP LSP) independent of the number of 
VPNs.
> [Lizhong] yes, the state on P-routers is not reduced. This use case 
> is to reflect the discussion on the list: http://www.ietf.org/mail-
> archive/web/mpls/current/msg05557.html. From the operational point 
> of view, the number of LSP maintained on each PE is reduced (by 
> combining the P2MP and P2P LSP into one LSP). But yes, the state 
> maintained on P and PE is almost the same. We could add some note in
> the draft about this.
> 
> > 
> > I still don't see where the gain is...
> > 
> > -Thomas
> > 

> > 
> > 
> > > 
> > > 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)
> > > > 
> > > 
> > 
> > 
> 
_________________________________________________________________________________________________________________________
> > 
> > Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous 
> > avez recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> > messages electroniques etant susceptibles d'alteration,
> > France Telecom - Orange decline toute responsabilite si ce message a
> > ete altere, deforme ou falsifie. Merci.
> > 
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender 
> > and delete this message and its attachments.
> > As emails may be altered, France Telecom - Orange is not liable for 
> > messages that have been modified, changed or falsified.
> > Thank you.