Re: [Bier] Explicit Tracking

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

Great thanks.

Andrew

Sent from my iPhone

> On Jan 8, 2015, at 11:00 AM, Eric C Rosen <[e-mail]> wrote:
> 
>> 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?
>>