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

From: Jeff Tantsura <[email-masked]>
Date: Tue, 1 Oct 2013 17:40:08 +0000

Hi,

I seem to agree with Ice.
My personal experience is that when people migrate from IP multicast to
MPLS multicast and deploy mLDP going to in-band signaling is a very
natural step as it preserves semantics and mode of operation of IP
Multicast while bringing all the advantages of MPLS. Complexity of BGP
signaling is often taken in consideration when it is compared to mLDP
in-band.

I'd really like to ask people who are deploying and operating Multicast
(not selling it) :) to speak up

Cheers,
Jeff

-----Original Message-----
From: IJsbrand Wijnands <[email-masked]>
Date: Wednesday, September 25, 2013 3:31 PM
To: Yakov Rekhter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>, Lizhong Jin
<[email-masked]>
Subject: Re: [mpls] MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp

>Yakov,
>
>> I can not comment on whether it is "more natural to follow the
>>mechanism 
>> 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. 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.
>
>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.
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 2 Oct 2013 08:40:40 -0700

Lizhong,

> Hi authors,
> 
> I review draft-rekhter-mpls-pim-sm-over-mldp-06, and think it is useful =
> and ready for WG adoption.

Thanks !

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

You are correct. I'll add this to the next revision of the draft.

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

I personally have no strong opinion on this. I would like this
to be decided by the WG consensus.

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

I'll add the text as you suggested.

> 4. If possible, it would be helpful for the readers to include one 
> example for option2 in the draft, like RFC6826 section2.

Let me think about this.

Yakov.