Re: [mpls] MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp

["Rajiv Asati (rajiva)" <[e-mail]>]

I have finished reviewing draft-rekhter-mpls-pim-sm-over-mldp-06 as the
member of MPLS Review team and have the following comments (they may
overlap with the other reviewers' comments, but I haven't checked):


* Is the document coherent?
============================

The document could benefit from having a sample topology while describing
both solution options and providing a bit of context about the options in
the Introduction. 

The document needs to better explain the option 2 in section 4. It is a
bit difficult to follow. For ex, section 4 says mapping *,G PIM state to
mLDP state, using the encoding defined in section 4.1. But it is not clear
when the machinery specified in section 4.2 gets used.

Also, option 2 is not clear about the LSR's usage of shared tree vs source
tree - when an LSR switches from shared to source tree.



* Is the document ready to be considered for WG adoption?
============================


Not yet. I would like to get some clarity from the authors on these points.



1) The document (Introduction) seems to convey that ASM is just about
shared tree. Per RFC4601, ASM is also about the source tree.  This means
that the solution options defined here must be used in conjunction with
RFC6826. Is that the case?

2) Option 1 seems to _obviously_ suffer from the fact that the ingress LSR
can't re-construct the PIM *,G join or Prune message (since *,G state is
not carried through mLDP) for its upstream PIM neighbors.

In other words, option 1 is only workable/useful/deployable if ingress LSR
acts as the RP.

3) This document (introduction) makes an assumption that an interface is
either IP enabled or MPLS enabled, but not both. In particular, it assumes
that PIM neighbor is not enabled on MPLS enabled interface. I suspect that
this assumption would easily break in network topologies where:

 - RSVP-TE/MPLS is enabled on part of the network where PIM is also enabled
 - PIM is also enabled on few MPLS enabled interfaces (due to migration
etc.)
	(Hence, an int is both IP Multicast enabled and MPLS Multicast enabled)

This assumption should be removed.


4) Option 2, as described, does not seem right to me, for the following
reasons: 

a) Per section 4.2, an LSR creates an S,G route (and sends S,G mLDP
message) based on BGP Source Active AD message, but per section 4.3 (which
points to section 3.2), an LSR creates BGP Source Active AD message based
on S,G mLDP message.

Which one is true, as only one of them can/should be true (else, we are in
a vicious cycle)?


b) This machinery enables immediately setting up a source tree P2MP LSP
just because the LSR learned of the source  (for a G) based on BGP,
while/after it created the *,G.

This is not correct, as RFC4601 section 4.2.1 clearly makes using a source
tree (aka switching over from shared tree to source tree) OPTIONAL.


c) After the source tree P2MP LSP is setup, there is no way to avoid
forwarding the traffic over it and then to the downstream routers/hosts by
the LSR, even though not all receivers would have wanted to receive any
traffic over the S,G (and they didn't initiate any switchover).

 

d) The document seems to exclude the possibility of source becoming active
prior to having any receivers on the network. Is there any particular
reason?



5) The document seems to make an assumption that the RP function is
enabled on one of the LSRs. Why is that so? If not, then in the below 2
topologies (of a single ASN), how would the option 2 be applied?


	(a) RP and Source are connected to LSR_a

R1(RP)-----R2----LSR_a-----LSR_b----LSR_c----R3---Rx
Source------------/


	(b) RP and source are connected to different LSRs

R1(RP)-----R2----LSR_a-----LSR_b----LSR_c----R3---Rx
Source-----------------------/




6) Section 4.5 (pasted below) doesn't seem right to me.

//
   Creation and deletion of (S,G,RPT-bit) state on a LSR that resulted
   from receiving PIM messages on one of its IP multicast interfaces
   does not result in any mLDP and/or BGP actions by the LSR.
//


Consider this topology (RP is indirectly connected to LSR_a via R2, two
receivers are connected to LSR-b and LSR-c respectively) :

R1(RP)-----R2----LSR_a-----LSR_b----LSR_c----R3---Rx
Source----------------------//
Rx---------R4---------------/


- Receivers (Rx) are getting the content on the shared tree
- R3 decides to join the source tree, but R4 doesn't.
- R3 starts receiving the content on the source tree
- R3 sends S,G,rpt PIM to LSR_c, which changes its PIM state & mrouting
- if LSR_c doesn’t react to such PIM state change, then it would
unnecessarily keep on receiving the content on shared tree, per the draft.



7) What is really meant by this para in section 4.4? Could you please
clarify? 

//
   received one.] Depending on the (S,G,RPT-bit) state on the iif, this
   may result in the LSR using PIM procedures to prune S off the Shared
   (*,G) tree.
//






* Is it useful (i.e., is it likely to be actually useful in operational
networks), and is the document technically sound?
============================


It may be useful, even though many networks either (want to) move from ASM
to SSM or continue using the ASM shared tree. However, I really struggled
with the following Q while reading the draft and thinking about usefulness:

(a) If one can afford (or wants) to use BGP, then why wouldn't one use BGP
MVPN procedures that are already part of seamless multicast
(draft-ietf-mpls-seamless-mcast) section 3 to solve this problem, as the
Introduction section right points out?

(b) Why would one be using BGP, if the intent is to use in-band mLDP
signaling?  

(c ) If one really wants to use in-band mLDP signaling for ASM shared
tree, then why wouldn't one use
draft-wijnands-mpls-mldp-in-band-wildcard-encoding procedures that don't
require BGP?
  


Wrt technicalities, please see my comment above.




-- 
Cheers,
Rajiv Asati
 



 
>> -----邮件原件-----
>> 发件人: Loa Andersson [mailto:[e-mail]]
>> 发送时间: 2013年9月11日 17:43
>> 收件人: Lizhong Jin; Gregory Mirsky; Rajiv Asati (rajiva); Xuxiaohu;
>> [e-mail];
>>[e-mail];
>> VIGOUREUX, MARTIN (MARTIN)
>> 主题: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
>> 
>> Lizhong, Greg, Rajiv and Xiaohu,
>> 
>> You have been selected as MPLS Review team reviewers for
>> draft-rekhter-mpls-pim-sm-over-mldp-06.
>> 
>> 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
>> WG 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 Sep 25, 2013?
>> 
>> 
>> Thanks, Loa
>> (as MPLS WG chair)
>> 
>> --
>> 
>> 
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Huawei Technologies (consultant)     phone: [phone]