Subject: [mpls] Comments regarding draft-rekhter-pim-sm-over-mldp

From: <[email-masked]>
Date: Tue, 11 Sep 2012 19:40:22 +0000

Dear Authors,
I would like to provide feedback in regards to the  draft-rekhter-pim-sm-over-mldp-01.

1.       The baseline for this draft should be rfc 4601.  As such it  would probably make sense to consider  mapping of pim - B (not for this draft), S,W, R bit fields from encoded source and group address formats to new shared and sourced tree TLVs.

a.       It might require to figure out how to deal with periodical pim behavior and be prescriptive in regards to timers on egress LSR for triggering population/removal of opaque value based on pim multicast control plane state.

b.      However, it might resolve complexities that are being introduced as part of your draft, for example you would not need to simulate last hop switchover behavior as you proposing in section 3.4.

c.       And besides that it would look more intuitive, such mapping might provide safeguards against mismatch of egress and ingress pim  multicast tree types.

2.       I am not following the reason for originating source active auto-discovery as per section 3.2.  I believe section 2.1 would cover all possible cases for need to originate source active auto-discovery routes and as a result to  be cashed by all LSRs.

3.         Your draft does not preclude  to achieve in-band signaling for shared tree without auto-discovery and switchover to shared tree. However to achieve a better clarity, could we introduce the following note under section 3.1:

Like [RFC4601],  source tree is optional to support as part of  PIM-SM in ASM mode trees over P2MP mLDP LSPs. BGP Source Active auto-discovery has been proposed to be used to support proper switchover logic from shared to sourced tree over the MPLS network, however BGP Source Active auto-discovery MAY be optional if shared tree only required to be supported.
             I discussed to clarify (S,G, RPTbit) state and auto discovery as part of section 3.1 with Ice. Ice proposed similar changes.  Please let me know your feedback on proposed note.

4.       Your document refers/introduces new mLDP TLVs. Could you introduce a new section in the document that would cover proposed opaque encodings.

5.       Would you consider to support  l3vpn-mldp-vrf-in-band-signaling for PIM-SM in ASM mode trees over P2MP mLDP LSPs in future releases of this draft?
Thanks

Arkadiy Gulko
Principal Core Network Architect <https://thehub.thomsonreuters.com/people?filterID=all%7Eprofile%5Btitle%5D%7Etitle%5BPrincipal+Core+Network+Architect%5D>
ThomsonReuters
[email-masked]<mailto:[email-masked]>