Re: [mpls] MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding

[IJsbrand Wijnands <[e-mail]>]

Hi Dutta,

Thanks for the review, a few comments;

> I would suggest to merge the solutions for 1.1 from both the documents to adopt a single/unified approach. A key issue we have been seeing off late is fragmentation - where solutions with same intent are fragmented across multiple documents. This leads to lack of clarity for implementations and subsequently opens inter-op worms. For e.g PIM BI-DIR mapping was addressed 
> in RFC 6826 but didn't address PIM ASM/unidirectional mapping in that doc.

The overlap in the two drafts got introduced by;

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-rekhter-mpls-pim-sm-over-mldp-03.txt

Its really a very minimal overlap looking at the procedures defined. Both solutions provide an option to do shared tree only forwarding. draft-rekhter does it by making the Source discovery optional. The intend of draft-rekhter has always been towards source discovery, that is what most of his draft is about. Merging the drafts seems a very bad way to resolve the conflict. Is better to keep both drafts, one with a focus on source discovery, the other on shared tree forwarding.

> I can see the need to address item 1.2 in this draft. This is certainly useful to reduce control + forwarding states since RFC 6826 makes us reach data path scaling limits in core with 1:1 mapping to MP-LSP. This is more an issue in vpn-in-band mapping wherein every VPN multicast tree is pushing one MP-LSP into core. So I would like to see a solution for aggregation of VPN in-band multicast trees over MP-LSP.

Please note that this is not a solution intended for VPN support. Its used for solutions where the service is implemented in a VRF context. This is a fine lined, but important difference. The reason for Thomsson Reuters to go with shared tree only forwarding is not necessarily due to aggregation, but mostly that source discovery is avoid all together. For example, in many cases there is a single sender per Group, so you really don't have any less state. But this solution can certainly be used for reduce state if there are multiple senders for a given group.

> 2. Using wildcard encoding for shared/ASM tree signaling is a paradigm shift from previous in-band encodings defined in RFC 6826 and vpn-in-band signaling. This draft avoids defining new MP opaque element types and re-uses/overloads existing in-band opaque elements by introducing the notion of "wildcard" (zero values) in S and/or G.

This is not a paradigm shift.

> Section 3 states as follows:
> 
> <snip>
>  "if the IP Source Address sub-field contains the wildcard, and the IP
>   Group Address sub-field contains an IP multicast group address, say
>   G, that is NOT in the SSM address range (see Section 4.8 of
>   [RFC4601]), the TLV identifies a PIM-SM shared tree."
> 
>   If the IP Source Address sub-field contains the wildcard, and the IP
>   Group Address sub-field contains an IP multicast group address, say
>   G, that is in the SSM address range, the TLV identifies the
>   collection of PIM-SSM trees with the given group address.
> 
>   If the IP Source Address sub-field contains a non-zero IP address,
>   and the IP Group Address sub-field contains the wildcard, the TLV
>   identifies the collection of PIM-SSM trees that have the source
>   address as their root."
> </snip>
> 
>   Adding newer interpretation to Group Address sub-field opens up backward 
>   compatibility issues with existing implementations of RFC 6826. The 
>   defined Transit IPV4/IPV6 Source TLVs in RFC 6826 are explicitly 
>   for "SSM" - the contract between PIM and mLdp had been locked for that 
>   purpose in Root LSR.

That is not the case, section 2.2 in RFC6826 clearly explains the Source can be either SM or ASM. Since a source/group field of 0.0.0.0 is undefined behaviour, this does not cause any backwards compatibility issue. 

>   For e.g it is possible that in an existing RFC 6826 implementation - PIM 
>   at mLdp root LSR may be rejecting (or handling as no-op) Transit 
>   IPv4/IPV6 Source TLV mapping if its opaque element is received with 
>   non-SSM Range in Group Address. 

That does not mean there is a interop issue. How is this different from receiving a opaque value that is unknown?

>   On a similar note in Aggregation of multiple SSM trees with wildcard
>   source address in Transit IPV4/IPV6 Source TLV - it is possible that 
>   PIM at mLdp root LSR in RFC 6826 may be handling source address 0.0.0.0
>   as no-op (do nothing) or at best ending up as RPF lookup failure.

That is expect if the value is undefined, I don't see the issue.

> 
> 3. Section "4.1 PIM Shared Tree Forwarding" states below:
> 
>  <snip>
> 
>   "To efficiently use mLDP in-band signaling in this scenario, it is
>   necessary for the Egress LSRs to construct an Opaque Value TLV that
>   identifies a (*, G) tree.  This is done by using the wildcard in the
>   IP Source Address sub-field, and setting the IP Group Address sub-
>   field to G." 
> 
>  </snip>
> 
>   Let's say the Group is selected from non SSM range (ASM) and source 
>   is wildcard here. No RP is explicitly encoded/specified in the opaque
>   element in Transit IPV4/IPV6 Source TLV, then does that means that 
>   mLdp root is always the RP? What happens if RP is not co-located with 
>   mLdp Root LSR? If so then this solution is not generic and has imposed 
>   a limitation for collocation of RP and mLdp root for various PIM ASM 
>   applications.

The mLDP Root will treat this as having received a IGMP (*,G) report, and do what ever PIM procedure it has to do based on that. This solution is explicitly targeted to deployments where the RP is behind the mLDP root. This is not a limitation of the solution.


> 
>   A generic solution would be to encode an explicit RP in opaque value
>   element. Such approach would satisfy both cases - whether RP is 
>   collocated with mLdp root LSR or is disjoint. The encoding of Transit
>   IPV4/V6 Shared Tree TLV defined in draft-rekhter-mpls-pim-sm-over-mldp 
>   for same purpose carries an explicit RP.

This is not true and something we want to explicitly avoid. The mLDP root will look at its own RP mapping table to determine the RP for the group it is processing. The RP that is carried in the PIM Join messages is NOT used for RP discovery, its only used to detect conflicts. This is really an historical artefact. Decoupling the RP on the egress and ingress and NOT having to have the same RP on both provides a lot of flexibility. Also, when IGMP proxy is done, there is no RP what so ever on the egress.


> 
> 
>   Section "4.2 IGP/MLD proxying" is the case where it is possible that
>   mLdp root node and RP are collocated in same node, since multicast 
>   senders and receivers are directly connected to MPLS domain.
> 
>   It's not clear from overall Section 4 on how the draft addresses RP 
>   and mLdp Root LSR being disjoint. 

That is the point, we don't.

We don't intend to address disjointness. Shared tree only forwarding is used by many financials and they have engineered the network to be this way. 

> 
> 4. In section "5/ Procedures for Wildcard Source Usage"
> 
>  <snip>
> 
>   "The IP multicast component on an Egress LSR determines when a
>   wildcard is to be used in the IP Source Address sub-field of an mLDP
>   Opaque Value TLV.  How the IP multicast component determines this is
>   a local matter, and may need to be explicitly configured.  It MAY
>   however use the following rules (with or without explicit
>   configuration);
> 
>     1. Suppose that PIM is enabled, and an Egress LSR needs to join a
>        non-bidirectional ASM group G, and the RP for G is reachable via
>        a BGP route.  The Egress LSR MAY choose the BGP Next Hop of the
>        route to the RP to be the Ingress LSR (root node) of the MP-LSP
>        corresponding to the (*,G) tree.  (See also Section 7.)  The
>        Egress LSR MAY identify the (*,G) tree by using an mLDP Opaque
>        Value TLV whose IP Source Address sub-field contains a wildcard,
>        and whose IP Group Address sub-field contains G." 
> 
> </snip>
> 
> By reading this section the draft seems to re-assert that RP for (*, G) tree is collocated to mLdp Root Node. There would be newer applications to be defined in future where RP and mLdp Root functionality need not be collocated.

As I said before, this is the sweet-spot for this proposal. But even if the RP/Source are not co-located with the mLDP root, nothing is broken, it still works using the basic PIM procedures. Its just that you don't have optimal forwarding.

> 
> 5.  "Section 7. Determining the MP-LSP Root (Ingress LSR)"
> 
> <snip>
> 
>   "Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]
>   describe procedures by which an Egress LSR may determine the MP-LSP
>   root node address corresponding to a given IP multicast stream, based
>   upon the IP address of the source of the IP multicast stream.  When a
>   wildcard source encoding is used, PIM is enabled, and the group is a
>   non-bidirectional ASM group, a similar procedure is applied.  The
>   only difference from the above mentioned procedures is that the Proxy
>   device or RP address is used instead of the Source to discover the
>   mLDP root node address.
> 
>   In all other cases some sort of manual configuration is applied in
>   order to find the root node.  Note, finding the root node is a local
>   implementation matter and not limited to the solutions mentioned in
>   this document."
> </snip>
> 
>   This section seems to imply that MP-LSP root and RP may be disjoint 

It does not imply this.

>   nodes when wildcard source encoding is used for non-bidirectional 
>   ASM Group. If so then it is required for MP-LSP root node to hand off 
>   the (*,G) to local PIM and further progress (*, G) join upstream in 
>   PIM domain towards the RP. Overloading existing Transit IPV4/IPV6 Source 
>   TLVs with wildcard source won't work.
> 
> 
> Summary:
> 
> 1. Is it likely to be actually useful in operational
>   Networks? 
> 
> - Yes. The solutions are desirable.
> 
> 2. Is the document technically sound?
> 
> - Concerned with Wildcard Encoding for PIM-ASM. By reading the draft it 
>   does not look like encoding is generic + may lead to backward 
>   compatibility issues with RFC 6826. This item has overlap with 
>   draft-rekhter-mpls-pim-sm-over-mldp-07 and single approach should be    
>   adopted by WG. IMO, the encoding defined in draft-rekhter is more
>   generic + no backward compatibility issues.

I disagree, there is no backwards compatibility issue. Also, if the overlap is a concern, its better to remove the overlap then to merge the draft. Both drafts have a totally different focus.
> 
> - Aggregation of SSM trees with wildcard encoding may lead to backward 
>   Compatibility issues with RFC 6826.

I disagree.

By using the wildcard encoding, we don't have to redefine existing behaviour as already defined in RFC6826 and more imporantly draft-ietf-l3vpn-mldp-vrf-in-band-signaling.

Thx,

Ice.

> 
>   A better approach is to define new MP Opaque Value elements exclusively
>   for mapping PIM-ASM and Aggregate SSM(in similar lines with RFC 6826 and 
>   in-band-vpn draft). 
> 
>   Note that we have mapped PIM BI-DIR explicitly to Transit IPV4/IPV6 
>   Bi-Dir TLVs in RFC 6826. 
> 
> 
> Thanks,
> Pranjal
> 
> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]] 
> Sent: Sunday, October 27, 2013 8:42 PM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [e-mail]; Curtis Villamizar; [e-mail]; [e-mail]; VIGOUREUX, MARTIN (MARTIN)
> Subject: MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding
> 
> Lizhong, Pranjal, Vishwas and Curtis,
> 
> You have been selected as an MPLS Review team reviewers for
> draft-wijnands-mpls-mldp-in-band-wildcard-encoding-01.
> 
> 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
> 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 November 11, 2013?
> 
> 
> Thanks, Loa
> (as MPLS WG chair)
> -- 
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls