I have a few comments on draft-dolganow-l3vpn-mvpn-expl-track-00.txt. The draft points out a few issues with regard to the use of a PMSI Tunnel attribute (PTA) whose "tunnel type" is set to "no tunnel information".
The first issue is the following. RFC6625 gives a detailed set of procedures for figuring out which S-PMSI A-D route specifies the P-tunnel to be used for sending or receiving a particular multicast C-flow. However, RFC6625 neglects to point out that if the PTA of particular S-PMSI A-D route specifies "no tunnel information", then the that S-PMSI A-D route should be ignored when those procedures are applied. The draft is correct to point this out, though I'm not sure any implementer would actually try to send or receive packets on a P-tunnel whose type is "no tunnel information". This particular issue might be better addressed through an erratum to RFC6625. But a couple of more difficult issues are raised as well. I think the original intention of using "no tunnel information" is that it would be used with (C-S,C-G) S-PMSI A-D routes. Thus there is no clear statement in any of the RFCs about how to use it with an S-PMSI A-D route that has one or more wildcards in its NLRI. It's clear that a egress node, say PE1, interested in (C-S,C-G), needs to send a Leaf A-D route in response to a "no tunnel info" S-PMSI A-D route with (C-S, C-G) in its NLRI, as long as the S-PMSI A-D route is originated by the ingress node that PE1 has selected for (C-S,C-G). What's not clear is what to do in the following case: - PE1 is an egress node interested in (C-S,C-G) - PE1 has chosen PE2 as the ingress node for (C-S,C-G) - PE1 has installed a (C-S,C-G) S-PMSI A-D route from PE2, where the route specifies a tunnel to join - PE1 has installed an S-PMSI A-D route from PE2 with a "less specific" NLRI (e.g., (C-*,C-G) or (C-S,C-*) or (C-*,C-*)), and that specifies "no tunnel information" with LIR set. Does PE1 have to respond to PE2's less specific S-PMSI A-D route with a Leaf A-D route in this case? The RFCs don't really say. I can imagine several possible answers: - yes - no - it depends on whether the more specific route had LIR set - it depends on whether the less specific route covers more than one more specific route - it depends on something else The desired behavior when mixing "no tunnel information" with wildcards was not thought out when RFC6625 was written. Another issue has to do with the way the P-tunnel segmentation procedures are applied to an S-PMSI A-D route whose PTA specifies "no tunnel information." The draft doesn't actually mention P-tunnel segmentation, but it does distinguish between "intra-AS" and "inter-AS" procedures. It leaves inter-AS "for further study", so I surmise that the authors think there are some issues when S-PMSI A-D routes with "no tunnel information" have to travel inter-AS. I surmise further that the issues have to do with the application of the P-tunnel segmentation procedures to S-PMSI A-D routes with "no tunnel information". This surmise could be wrong, because (a) segmentation doesn't have to be applied at inter-AS boundaries, and (b) segmentation can be applied within within a single AS (see "seamless multicast"). But I think there are some issues having to do with processing these routes at "segmentation boundaries", whether or not those boundaries are also AS boundaries. Generally, when a P-tunnel is segmented, the segments do not all have to be the same tunnel type. However, we could decide that when segmenting a "no tunnel information" P-tunnel, the segments should all be "no tunnel information" segments, with each segment having LIR set. (Yes, I know it doesn't make literal sense to talk of segmenting a "no tunnel information" tunnel, this is just shorthand for applying the P-tunnel segmentation procedures to S-PMSI A-D routes whose PTAs specify "no tunnel information".) Or we could decide that whether a "no tunnel information" PTA should pass through a segmentation boundary is a matter of policy. But note that when the ingress PE and egress PEs are separated by segmenation boundaries, there are no procedures that allow the ingress PE to track the egress PEs. The procedures are really designed only to enable the ingress node of a "segmentation domain" to track the egress nodes of that domain. That is all that is needed if the purpose of explicit tracking is to enable the ingress node to add egress nodes to a particular P-tunnel segment. If it is desired to enable PE-PE explicit tracking across segmentation domains, new procedures would be needed. I would like to know if the authors think that I have correctly captured the issues. Also, if new procedures need to be developed, we should discuss some use cases, to make sure that any new procedures are really solving the problems posed by the use cases. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
