Re: [Bier] Explicit Tracking

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

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?