Re: [Bier] Explicit Tracking

["Dolganow, Andrew (Andrew)" <[e-mail]>]

Eric,

I think we converged. Please correct me:

1. I think we want to have 2 options for wildcard tracking
- return to wildcard tracking with wildcard Leaf A-D
- return to wildcard tracking with per (C-S, C-G) Leaf A-D

Correct?

My draft had only one option and clearly there were various assumptions
what type of Leaf A-D route you send to Sender PE based on wildcard match.

Now to handle two cases I agree we need an extra flag or something to
differentiate between response that sends Leaf A-D wildcard route and
response that sends Leaf A-D per (C-S, C-G) route.

Please note that my draft allows any wildcard tracking, so I assume you
not limiting tracking to only (C-*, C-G) wildcard as per below, correct?

Since this is a general explicit tracking, I propose we merge the two
proposals, so everyone can look at this from general explicit tracking
procedures for any case.

We probably should then bring this discussion to BLESS.

Andrew



On 2015-01-07, 10:44 AM, "Eric C Rosen" wrote:

>Let me write down how I think explicit tracking should work, and you can
>tell me whether (a) it's at odds with what's in your draft, or (b) it
>duplicates what's in your draft, or (c) it extends what's in your draft
>in a useful way, or (d) it extends what's in your draft in a useless way
>;-)
>
>(Perhaps this discussion really belongs on the BESS ML, but we might as
>well continue it here for a little while.)
>
>RFC6625 (and other RFCs or RFCs-to-be that update RFC6625) specify a
>set of rules for finding the S-PMSI A-D route that is the "match for
>reception" for a given (C-S,C-G) or (C-*,C-G) state.  As
>draft-dolganow-l3vpn-mvpn-expl-track points out, the defintion of "match
>for reception" needs to be modified as follows:
>
>    When finding the "match for reception" for a given (C-S,C-G) or
>    (C-*,C-G), ignore any S-PMSI A-D route that has no PMSI Tunnel
>    attribute (PTA), or that has a PTA specifying "no tunnel info".
>
>I'd like to propose now to introduce a new notion: the "match for
>tracking".  This differs from the "match for reception" as follows:
>
>    For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for tracking"
>    is chosen as follows.  Ignore any S-PMSI A-D route that has no PTA,
>    or whose PTA does not have either LIR or LIR-pF set.  (In particular,
>    DO NOT ignore an S-PMSI A-D route that has a PTA specifying "no
>    tunnel info", but whose LIR or LIR-pF bits are set).  Then apply the
>    rules (from RFC6625 and other RFCs or RFCs-to-be that update it) for
>    finding the "match for reception".  The result (if any) is the
>    match for tracking".
>
>For example, suppose a given PE router, PE1, has chosen PE2 as the
>"upstream PE" for a given (C-S1,C-G1).  And suppose PE1 has installed
>the following two routes that were originated by PE2:
>
>Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a tunnel.
>
>Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no tunnel
>info" and has LIR set.
>
>Route1 is (C-S1,C-G1)'s match for reception, and Route2 is (C-S1,C-G1)'s
>match for tracking.
>
>Note that if there is no installed S-PMSI A-D route for (C-S2,C-G2),
>then Route1 would be (C-S2,C-G2)'s match for reception and also its
>match for tracking.
>
>As another example, suppose PE1 has installed the following two routes
>that were originated by PE2:
>
>Route3: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the PTA
>specifies a tunnel)
>
>Route4: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a tunnel.
>
>Then Route 4 is both the "match for reception" and the "match for
>tracking" for (C-S1,C-G1).
>
>Note that for a particular C-flow, the PE1's match for reception might
>be the same route as its match for tracking, or its match for reception
>might be a "less specific" route than its match for tracking.  But its
>match for reception can never be a "more specific" route than its match
>for tracking.
>
>Now we have a number of cases to look at:
>
>1. PE1's match for tracking the is same as its match for reception, but
>neither LIR nor LIR-pF flags are on.  In this case, there is no explicit
>tracking for the C-flow.  The match for reception is processed
>according to existing procedures.
>
>2. PE1's match for tracking is the same as its match for reception, LIR
>is set, LIR-pF is not set.  In this case, existing procedures are
>followed.
>
>3. PE1's match for tracking is the same as its match for reception, and
>LIR-pF is set.  This case is discussed in a previous message.
>
>4. PE1's match for tracking is not the same as its match for reception.
>This can only happen if the match for tracking has a PTA specifying "no
>tunnel info", with either LIR or LIR-pF set.  In this case, PE1 must
>respond both to the match for tracking and to the match for reception.
>To respond to the match for tracking, PE1 originates one or more Leaf
>A-D routes; the PTA of each such route will specify "no tunnel info".
>Construction of the NLRI of the Leaf A-D route is as specified in
>RFC6514 (if LIR is set) or as specified in the referenced message on the
>BIER mailing list (if LIR-pF) is set.  To respond to the match for
>reception, existing procedures are used.  Note that if LIR or LIR-pF are
>set in the PTA of the match for reception, PE1 may need to originate a
>Leaf A-D route corresponding to the match for tracking as well as
>originating a Leaf A-D route corresponding to the match for reception.
>
>I think the above procedures work at an egress PE, but they are not
>quite right for an egress ABR/ASBR.  An egress ABR/ASBR does forward
>along any S-PMSI A-D routes it gets.  If the PTA of the received S-PMSI
>A-D route specifies a tunnel, the egress ABR/ASBR may change the PTA to
>specify a different tunnel type.  However, we should require that if the
>PTA specifies "no tunnel info", it is passed along unchanged.
>
>Then we can establish the following rule for egress ABRs/ASBRs.  Suppose
>an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is X, and
>whose PTA (a) specifies "no tunnel info" and (b) has LIR set.  The
>egress ABR/ASBR should not immediately originate a Leaf A-D route in
>response.  Rather it should wait until it receives a Leaf A-D route
>whose NLRI contains X in the "route key" field.  If it receives such a
>Leaf A-D route, it redistributes that route, but first it changes that
>route's RT.  The "global administrator" field of the modified RT will be
>set to the IP address taken either from the S-PMSI A-D route's next hop
>field, or from its Segmented P2MP Next Hop Extended Community.
>
>This will ensure that an egress ABR/ASBR only sends a Leaf A-D route in
>response to a "match for tracking" if it is on the path to an egress PE
>for the flow(s) identified in the corresponding S-PMSI A-D route.
>
>Comments?
>
>
>
>
>