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

[Yakov Rekhter <[e-mail]>]

Rajiv,

> 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.

Any specific text to clarify this would be appreciated.

> 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.

Any specific text to clarify this would be greately appreciated.

> 
> 
> * 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?

Yes. I'll add this to the draft.

> 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.

While it is certainly true that with Option 1 the ingress LSR can not
re-construct the PIM *,G Join/Prune message for its upstream PIM neighbor,
could you elaborate on why "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.

Agreed. 

> 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)?

Could you please point me to the specific text in 4.2 that talks about
creating an S,G route and sending S,G, mLDP message "based on BGP Source 
Active AD message".

Could you also point me to the specific text in 3.2 that talks about
creating Source Active AD message based on S,G, mLDP message ?

> 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.

Just because rfc4601 makes using a source tree optional does not make
option 1 incorrect.

> 
> 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).

That is correct. Likewise, in PIM if only some, but not all routers
on a LAN initiate switchover, all the downstream routers on that LAN
(and the ultimate receivers) would receive the traffic over the S, G,
even if the DRs of these receivers did not 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?

What makes you think so ?

> 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-----------------------/

I am not sure I understand your concerns with applying option 2
to the above two topologies. Could you elaborate please.

> 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.

The text you quoted above talks about mLDP and/or BGP actions. That
does not mean that the LSP does not react to PIM state changes
(following PIM procedures).

> 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.
> //

That is exactly what it means.

> * 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?

While PIM-SM ASM over MPLS network with draft-ietf-mpls-seamless-mcast
uses Leaf auto-discovery routes, several flavors of S-PMSI
auto-discovery routes, and Source Active auto-discovery routes,
draft-rekhter-mpls-pim-sm-over-mldp uses just Source Active
auto-discovery routes. Moreover, draft-rekhter-mpls-pim-sm-over-mldp
spells out that in certain deployment scenarios even Source Active
auto-discovery routes would not be used.

> (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?

Let me just point out that draft-wijnands-mpls-mldp-in-band-wildcard-encoding
itself said the following:

                                                                     In
   scenarios where it does not make sense to apply "threshold infinity"
   to a given ASM group, a more complex set of procedures are needed, as
   per [I-D.rekhter-pim-sm-over-mldp].

   ....

   [I-D.rekhter-pim-sm-over-mldp]
              Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode
              Trees over P2MP mLDP LSPs",
              draft-rekhter-pim-sm-over-mldp-04 (work in progress),
              August 2011.

So, even draft-wijnands-mpls-mldp-in-band-wildcard-encoding acknowledges
that there are scenarios where it is insufficient. Moreover, this
draft suggest to use draft-rekhter-pim-sm-over-mldp, *not*
draft-ietf-mpls-seamless-mcast.

Yakov.