Eric, Thank you for your comments. Please see inline
On 2014-11-07, 11:52 AM, "Eric C Rosen" wrote: >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. You are correct; although a tunnel may not be found by some implementation. We can decide in due time what is better a separate draft or erratum. > >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. This may have been the original intenion; however, I believe that there is enough to make wildcard tracking work, and since there is(are) implementation for that it would be good if other implementations were interoperable. > >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 To us, the receiver responds to explicit tracking only if it would use the route with a tunnel to receive data. Per draft (section 4.2): "We say a PE is to receive traffic for the explicitly tracked wildcard stream, if at least one (C-S, C-G) C-flow matchesthe S-PMSI A-D route encoding the explicitly tracked stream using procedures of section 3.2 of [MVPN-WC].² So for the case you outlined, if (C-S,C-G) is the only group, here would be no response (as wildcard matching procedures would match to S-PMSI A-D route for the (C-S,C-G) and not wildcard. > >The desired behavior when mixing "no tunnel information" with wildcards >was >not thought out when RFC6625 was written. Agree, hence our draft. The above though made me think that we should add explicit procedure we may to account for withdraw of more specific (A-D) routes that would require response to wildcard tracking. And equivalent reverse case. > >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". We left Inter-AS use case as future study because we have no immediate use case for that. We can discuss at the meeting whether we think we want to handle this or not. As you notice below, inter-AS requires a bit more thinking to make sure everything works as expected. > >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. Agree. > >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. Absolutely, Andrew > > > > >_______________________________________________ >BESS mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/bess
default.xml
Description: default.xml
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
