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

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 7 Nov 2013 23:16:56 +0800

Hi Authors,
I am reviewing this draft as MPLS-RT review. Overall the document is technically sound, and I need some clarification from the authors before adoption. I also review draft-rekhter-mpls-pim-sm-over-mldp, and both the two drafts are technically feasible to set up a (*, G) tree. Whether adopting the two methods is left to the WG to decide.

1. section 5, 
       If PIM is not enabled for group G, and an IGMP/MLD group
       membership report for G has been received, the Egress LSR may
       determine the "proxy device" for G (following the procedures
       defined in [RFC4605]).  It can then set up an MP-LSP using the
       proxy device as the Ingress LSR.  
[Lizhong] I am confused here by the description in section 4.2. In section 4.2, it is said, the ingress LSR is manually configured, not discovered by procedures defined in RFC4605.

2. section 5,
       If PIM is enabled and the identified group is a PIM-SSM group,
       all multicast sources known for the group on the Ingress LSR are
       to be forwarded down the MP-LSP.
       [Lizhong] Is it assumed that the PIM-SSM MP-LSP is already there, and the new wildcard source based MP-LSP is only to aggregate the PIM-SSM MP-LSP? In that case, will the original PIM-SSM MP-LSP still be kept or be deleted by egress LSR? It is not clear here for PIM-SSM case.

3. section 5,
       If PIM is not enabled for identified group, the Ingress LSR acts
       as if it had received a (*,G) IGMP/MLD report from a downstream
       node, and the procedures as defined in [RFC4605] are followed.
       [Lizhong] For point 1&3, the dataplane behavior is missing. E.g, all multicast traffic with group address G SHOULD be forwarded to the MP-LSP.

4. Section 6. 
[Lizhong] it seems the section 6 procedure is specifically described for static multicast use case described in section 4.3, right? Otherwise, if the stream has PIM-SSM address, will the original PIM-SSM MP-LSP still be kept or be deleted by egress LSR?

Regards
Lizhong

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Monday, October 28, 2013 11:42 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked];
> Curtis Villamizar; draft-wijnands-mpls-mldp-in-band-wildcard-
> [email-masked]; [email-masked]; 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: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 12 Nov 2013 19:57:24 +0000

Hi All,
         I have reviewed the following version of the draft from MP-RT perspective and following are my inputs. 

http://tools.ietf.org/html/draft-wijnands-mpls-mldp-in-band-wildcard-encoding-01

1. The draft specifies procedures for 
   1.1 Mapping PIM ASM trees to MP-LSP 
       and,  
   1.2 Mapping multiple IP multicast trees into a single MP-LSP.
   
There is another draft in progress on item 1.1 that overlaps with the solution in this draft.

http://tools.ietf.org/html/draft-rekhter-mpls-pim-sm-over-mldp-07

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

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.

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.

   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. 

   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.

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.

   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. 

   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. 

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.

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

 - Aggregation of SSM trees with wildcard encoding may lead to backward 
   Compatibility issues with RFC 6826.

   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:[email-masked]] 
Sent: Sunday, October 27, 2013 8:42 PM
To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked]; Curtis Villamizar; [email-masked]; [email-masked]; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding

adoption (ie, it doesn't have to be perfect at this point, but should be
a good start).

Thanks, Loa
(as MPLS WG chair)
--

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 12 Nov 2013 15:19:26 -0800

Hi Dutta,

Thanks for the review, a few comments;

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

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…

This is not a paradigm shift.

>   for "SSM" - the contract between PIM and mLdp had been locked for that 

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. 

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

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

>   a limitation for collocation of RP and mLdp root for various PIM ASM 

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.

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

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

> 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 functi…

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.

>   This section seems to imply that MP-LSP root and RP may be disjoint 

It does not imply this.

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

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Thu, 14 Nov 2013 12:57:24 -0800

Folks,

We now have three (of four) MPLS-RT reviews. This is the point where we
normally ask the authors to update the draft.

Authors,

Please do so for this draft also, but when it comes the overlap that
the reviewers (as many others) have noticed, please do the necessary
technical updates, but leave it in place for the time being.

When you have addressed the comments, verify with the reviewers that
they are comfortable with how their comments has been addressed.

Reviewers,

Please try to respond to the authors on how they propose to address
your comments in a timely manner.

/Loa
for the mpls wg co-chairs

--