Re: [Bier] Explicit Tracking

[Eric C Rosen <[e-mail]>]

On 1/7/2015 11:07 AM, Dolganow, Andrew (Andrew) wrote:
> Eric,
>
> I think we converged.

Yes, I don't think we have any real disagreement.

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

I think we are in agreement here, but for clarity we need to distinguish 
between two different things:

- The PIM receive states, which are always either (C-S,C-G) or (C-*,C-G).

- The NLRI of the S-PMSI A-D route, which may contain (C-S,C-G), 
(C-*,C-G), (C-S,C-*), or (C-*,C-*).

RFC6625 gives the rules for determining which S-PMSI A-D route matches 
which PIM receive state.  Note, for example, that a PIM receive state of 
(C-S,C-G) or (C-*,C-G) might match an S-PMSI A-D route whose NLRI 
contains (C-*,C-*).  Or a PIM receive state of (C-S,C-G) might match an 
S-PMSI A-D route whose NLRI contains (C-S,C-*).

Any S-PMSI A-D route should be able to invoke explicit tracking of the 
receive states that match it.

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

Sounds like a good plan (assuming you mean BESS ;-)).

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