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

From: Lizhong Jin <[email-masked]>
Date: Mon, 23 Sep 2013 22:09:50 +0800

Forward to the list.

Lizhong

---------- Forwarded message ----------
From: "Lizhong Jin" <[email-masked]>
Date: Sep 23, 2013 9:30 PM
Subject: Re: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
To: <[email-masked]>
Cc: "Gregory Mirsky" <[email-masked]>, "Rajiv Asati (rajiva)" <
[email-masked]>, "Xuxiaohu" <[email-masked]>, "
[email-masked]" <[email-masked]>, "VIGOUREUX,
MARTIN (MARTIN)" <[email-masked]>, "Loa Andersson" <
[email-masked]>

> Hi authors,
> I review draft-rekhter-mpls-pim-sm-over-mldp-06, and think it is useful
and ready for WG adoption.
> Several comments are as follows:
> 1. Section 2. I think the option 1 and option 2 could not interoperate
with each other, and operators should ensure one same option is deployed in
one network. It is better to explicitly say that.
> 2. Is there any plan to keep one option, e.g, remove option 1 in future?
Option1 does not provide the same function of PIM-SM ASM, e.g, traffic
would be potentially lost before setting up P2MP LSP.
> 3. Section 4.2. It is not clear how to trigger the mLDP Label Map with
the Transit IPv4/IPv6 Source TLV. The procedures in RFC6826 only apply to
PIM-SSM, not PIM-SM ASM. Then I suggest to explicitly say: "When a router
(maybe DR on a LAN) initiates a transfer from the shared tree to a
source-specific shortest-path tree (SPT), it will issue an (S,G) Join. The
LSR may initiate a mLDP Label Map with the Transit IPv4/IPv6 Source TLV for
(S, G) when receiving this (S,G) Join." Or other description with similar
meaning.
> 4. If possible, it would be helpful for the readers to include one
example for option2 in the draft, like RFC6826 section2.
> Regards
> Lizhong
>
>
> On Wed, Sep 11, 2013 at 5:43 PM, Loa Andersson <[email-masked]> wrote:
>>
>> 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: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 25 Sep 2013 06:43:38 +0000

Hi,

I have reviewed the document. I think this doc is coherent, technically sound and ready to be considered for WG adoption. 

Two minor technical comments: 

1) "... An implementation MAY support Option 1, as described in Section 2 of
   this document. An implementation MUST support Option 2, as described
   in Section 3 of this document."

Comment: It would be better if the reason for the above implementation suggestion can be given.

2) "... This document uses BGP Source Active auto-discovery routes, as
   defined in [MVPN-BGP]. This document also identifies the deployment
   scenarios where BGP Source Active auto-discovery routes will not be
   used."

Comment: Besides the approach of originating Source Active auto-discovery routes, shouldn't the MSDP-based approach be considered as well in option 1? 

Several editorial comments:

1) "This document describes how to map mLDP P2MP tress to multicast trees created by PIM-SM in ASM mode."

/s/tress/trees

2) "An implementation MAY support Option 1, as described in Section 2 of
   this document. An implementation MUST support Option 2, as described
   in Section 3 of this document."

/s/Section2/Section3  /s/Section 3/Section 4

3) "...One other scenario where no Source Active auto-discovery routes will be
   used is described in section "Originating Source Active auto-
   discovery routes".

/s/section/section 4.2 (since section 3.1 has the same title as section 4.2)

4) Source:  IPv6 RP address, 16 octets.
/s/Source/RP

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Loa Andersson [mailto:[email-masked]]
> 发送时间: 2013年9月11日 17:43
> 收件人: Lizhong Jin; Gregory Mirsky; Rajiv Asati (rajiva); Xuxiaohu;
> [email-masked]; [email-masked];
> VIGOUREUX, MARTIN (MARTIN)
> 主题: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
>

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 25 Sep 2013 15:12:44 +0800

Hi authors,

One more question to the draft, which is also raised by Ice in the list.
draft-ietf-mpls-seamless-mcast also provides PIM-SM ASM over MPLS network by
reusing MVPN mechanism. Since draft-rekhter borrows BGP Auto-discovery from
MVPN, and requires operator to deploy MP-BGP, then isn’t it more natural to
follow the mechanism in draft-ietf-mpls-seamless-mcast which could even
provide P2MP LSP aggregation? Is there any background behind that?

Thanks

Lizhong

From: Lizhong Jin [mailto:[email-masked]] 
Sent: 2013年9月23日 21:30
To: [email-masked]
Cc: Gregory Mirsky; Rajiv Asati (rajiva); Xuxiaohu;
[email-masked]; VIGOUREUX, MARTIN (MARTIN); Loa Andersson
Subject: Re: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp

Hi authors,

I review draft-rekhter-mpls-pim-sm-over-mldp-06, and think it is useful and
ready for WG adoption.
Several comments are as follows:
1. Section 2. I think the option 1 and option 2 could not interoperate with
each other, and operators should ensure one same option is deployed in one
network. It is better to explicitly say that. 
2. Is there any plan to keep one option, e.g, remove option 1 in future?
Option1 does not provide the same function of PIM-SM ASM, e.g, traffic would
be potentially lost before setting up P2MP LSP.
3. Section 4.2. It is not clear how to trigger the mLDP Label Map with the
Transit IPv4/IPv6 Source TLV. The procedures in RFC6826 only apply to
PIM-SSM, not PIM-SM ASM. Then I suggest to explicitly say: "When a router
(maybe DR on a LAN) initiates a transfer from the shared tree to a
source-specific shortest-path tree (SPT), it will issue an (S,G) Join. The
LSR may initiate a mLDP Label Map with the Transit IPv4/IPv6 Source TLV for
(S, G) when receiving this (S,G) Join." Or other description with similar
meaning.
4. If possible, it would be helpful for the readers to include one example
for option2 in the draft, like RFC6826 section2.

Regards

Lizhong

Thanks, Loa
(as MPLS WG chair)

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64
<tel:%2B46%20739%2081%2021%2064>

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Sep 2013 07:11:46 -0700

Xiaohu,

> Hi,
> 
> I have reviewed the document. I think this doc is coherent, technically sound
> and ready to be considered for WG adoption. 

Thanks.

> Comment: It would be better if the reason for the above implementation 

I do not have any strong reasons for the above choice. As I mentioned
to Loa, I would really like the WG to determine which of the two is
MUST and which one is MAY.

> Comment: Besides the approach of originating Source Active auto-discovery 
> routes, shouldn't the MSDP-based approach be considered as well in option 1? 

For one thing, use of the MSDP-based approach would require either
(a) some sort of provisioning to establish a full mesh of MSDP peerings
among all the edge routers, or (b) some sort of auto-discovery.
Also, it is far from obvious that such full mesh scale any better
than use of BGP with Source Active auto-discovery routes.

> trees created by PIM-SM in ASM mode."

Thanks ! Will fix.

> /s/Section2/Section3  /s/Section 3/Section 4

Sorry, my mistake. Will fix.

> /s/section/section 4.2 (since section 3.1 has the same title as section 4.2)

Sorry, my mistake. Will fix.

> 4) Source:  IPv6 RP address, 16 octets.

Sorry, my mistake. Will fix.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Sep 2013 14:09:08 -0700

Lizhong,

> MVPN, and requires operator to deploy MP-BGP, then isn't it more natural to

I can not comment on whether it is "more natural to follow the mechanism 
in draft-ietf-mpls-seamless-mcast".

However, I'd like to point out that 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.

Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 26 Sep 2013 00:31:47 +0200

Yakov,

> in draft-ietf-mpls-seamless-mcast".

I think the question is, is there a need for a solution that combines mLDP in-band signalling with BGP AD. What is the advantage of this solution compared to what is already defined in draft-ietf-mpls-seamless-mcast? I can see that it does not require Leaf auto-discovery routes, but is that an advantage? Moreover, most customers like mLDP in-band signalling because it does not depend on BGP AD.

> auto-discovery routes would not be used.

Do you mean like what is documented in draft-wijnands-mpls-mldp-in-band-wildcard-encoding-00 section 3? Is the solution in draft-wijnands not a better way to support that since it does not require new Opaque TLV encodings and covers both global table and VRF support?

Thx,

Ice.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 26 Sep 2013 01:46:59 +0000

Hi Yakov,

> -----邮件原件-----
> 发件人: Yakov Rekhter [mailto:[email-masked]]
> 发送时间: 2013年9月25日 22:12
> 收件人: Xuxiaohu
> 抄送: Loa Andersson; Lizhong Jin; Gregory Mirsky; Rajiv Asati (rajiva);
> VIGOUREUX, MARTIN (MARTIN); [email-masked]
> 主题: Re: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
> 
> Xiaohu,
> 
> > Hi,
> >

Thanks for the above explanation. Would it be better to include the above analysis text in the doc for clarification purposes?

Best regards,
Xiaohu

---

From: Loa Andersson <[email-masked]>
Date: Thu, 26 Sep 2013 09:56:15 +0800

Yakov and Xiaohu,

what interest me mostly now is how how much we need to do before
starting the wg poll.

Would it be possible to do the wg poll before finally addressing the
issue brought up by Xiaohu, and after we have the wg document have
Yakov send a mail to the working group saying something like:

"There si an issue that were brought up during MPLS-RT review.
 <short description of the issue> we'd like to have the input
 of the working group on this."

/Loa

--

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 26 Sep 2013 02:11:48 +0000

Hi Loa,

> 发送时间: 2013年9月26日 9:56
> 抄送: Yakov Rekhter; Lizhong Jin; Gregory Mirsky; Rajiv Asati (rajiva);
> 主题: Re: 答复: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
> 
> Yakov and Xiaohu,
> 

It looks fine to me.

Xiaohu

> > Thanks for the above explanation. Would it be better to include the above
> analysis text in the doc for clarification purposes?
> >
> > Best regards,
> > Xiaohu
> >
> >>> 3) "...One other scenario where no Source Active auto-discovery routes will
> b
> >> e

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 30 Sep 2013 20:21:20 +0000

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