Subject: [Bier] Optimized explicit tracking for BIER

From: Eric C Rosen <[email-masked]>
Date: Tue, 6 Jan 2015 11:11:01 -0500

As you all know, the use of BIER requires explicit tracking by the 
multicast flow layer.  In particular, to use BIER for MVPN, it is 
necessary to explicitly track every MVPN C-flow. 
draft-rosen-l3vpn-mvpn-bier-02 requires that an ingress node originate 
an S-PMSI A-D for every flow, in order to force each egress node to 
originate a Leaf A-D route for every flow that it needs to receive.

It would be desirable to eliminate the requirement for the ingress nodes 
to originate all these S-PMSI A-D routes.

Here is a proposal that allows an ingress node to request explicit 
tracking for each individual flow, but doesn't require the ingress node 
to originate S-PMSI A-D routes for those flows.

The proposal is to take one of the flag bits in the PMSI Tunnel 
attribute(PTA), and define it to be the "Leaf Info Required per Flow" 
bit (LIR-pF).  An ingress PE/ABR/ASBR would set this bit in the PTA of 
an S-PMSI A-D route.  For BIER, this would be the PTA of a (C-*,C-*) 
S-PMSI A-D route, and the PTA would specify a BIER tunnel.

Roughly speaking, the LIR-pF bit means "send me a Leaf A-D route for 
each C-flow that you expect to receive over the specified tunnel". 
(Where a C-flow could be either (C-S,C-G) or (C-*,C-G)).

For a given C-flow ((C-S,C-G) or (C-*,C-G)) at an egress PE/ABR/ASBR, if 
the match for reception has LIR-pF set, the egress node must originate a 
Leaf A-D route.  As a reminder, the "route key" field of the NLRI will 
have the following format:

+-----------------------------------+
|      RD   (8 octets)              |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
|  Multicast Source (Variable)      |
+-----------------------------------+
|  Multicast Group Length (1 octet) |
+-----------------------------------+
|  Multicast Group   (Variable)     |
+-----------------------------------+
|  Ingress PE's IP address          |
+-----------------------------------+

(stolen from draft-ietf-seamless-mcast).  Details:

- The "ingress PE" address will be taken from the "originating router" 
field of the NLRI of the S-PMSI A-D route.

- The multicast source and group fields specify the S and G of the 
(C-S,C-G) being tracked.  If a (C-*,C-G) is being tracked, the source 
field is omitted (length set to 0).

- The RD field is constructed as follows:

   * Take the RD value from the NLRI of the S-PMSI A-D route.
   * Add 16 to the first byte of the RD.

Note that, per RFC4364, every RD begins with a type field that is either 
0, 1, or 2.  By adding 16 to the first byte of the RD, we force the 
first byte to be 0x10, 0x11, or 0x12.  The presence of one of these 
values will indicate that the Leaf A-D route was constructed in response 
to a less specific S-PMSI A-D route that had the LIR-pF bit set.  (That 
is, it distinguishes the routes from "ordinary" MVPN Leaf A-D routes. 
And since the RD is not 0 or -1, these Leaf A-D routes can also be 
distinguished from the "global table multicast" Leaf A-D routes of the 
seamless-mcast draft.  These Leaf A-D routes will be accepted and 
processed even though there is no "corresponding"" S-PMSI A-D route (in 
the sense required by RFC6514).

Of course, an egress node that originates such Leaf A-D routes needs to 
remember which S-PMSI A-D route caused these Leaf A-D routes to be 
originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D routes 
will be withdrawn.  Similarly, a Leaf A-D route needs to be withdrawn 
(either implicitly or explicitly) if the egress node changes its UMH for 
the flow that is identified in the Leaf A-D route's NLRI.

If a particular PTA has both the LIR bit and the LIR-pF bit set, the 
actions for the LIR-pF bit are taken, and the LIR bit is ignored.

In the case where the egress node is a PE, it will know whether it needs 
to receive a given flow by virtue of its having received a PIM Join for 
that flow from a CE.  In the case where the egress node is not a PE, but 
border router at a "P-tunnel segmentation boundary", it's a bit more 
complicated.  If such an egress node receives an S-PMSI A-D route with 
LIR-pF set, it should process it, but also forward it along (as 
specified in RFC6514 and/or the seamless-mcast draft).  It should 
originate a Leaf A-D route for a specific flow only if it has an 
installed Leaf A-D route for that flow, received from further downstream.

Comments?

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 6 Jan 2015 18:03:43 +0000

Eric,

With this, the egress PE can suppress corresponding C-multicast routes as well.

Jeffrey

> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of Eric C Rosen
> Sent: Tuesday, January 06, 2015 11:11 AM
> To: BIER
> Cc: Eric Rosen
> Subject: [Bier] Optimized explicit tracking for BIER
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Wed, 7 Jan 2015 03:08:00 +0000

Eric,

Happy new Year.

Can you please look at the draft I presented in Honolulu:
https://tools.ietf.org/html/draft-dolganow-l3vpn-mvpn-expl-track-00,

The  draft describes how explicit tracking is expected to work in general.
As discussed on the list and in Honolulu, explicit tracking in RFC
61513/14 and in RFC6625 (wildcard) requires some clarification - although
with some common sense, following the rules outlined in 6513/14
implementers
Could achieve explicit tracking for any S-PMSI type.

The above draft clarifies things up and allows explicit tracking for any
S-PMSI 
route, including any wildcards, without a need for any new
procedures/encodings
(the draft we presented clarifies what applies and how  in the existing
RFCs). 

This general mechanism for NG-MVPN explicit tracking can be then also used
in BIER 
without a need for any BIER-specific extensions. When the mechanism is
used, 
ingress PE (BFIR) will send an explicit tracking request for whatever it
needs a (C-S, C-G) 
or any type of wildcard depending which C-multicast flows are to use BIER
in
P-instance). 

I find the below procedure thus duplicate of what we already have on the
table for general explicit
Tracking in ng-MVPN - including BIER.

Andrew

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 7 Jan 2015 09:53:47 -0500

> I find the below procedure thus duplicate of what we already have on
> the table for general explicit Tracking in ng-MVPN - including BIER.

If I understand your draft correctly, to invoke explicit tracking for a 
particular (C-S,C-G) flow, the ingress PE must originate a (C-S,C-G) 
S-PMSI A-D route.

In the proposal described in my message, there is no need for the 
ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each flow.  It 
originates a single (C-*,C-*) S-PMSI A-D route, and this causes it to 
receive a Leaf A-D route for each (C-S,C-G).

I don't think this duplicates what you have in your draft.

> S-PMSI route, including any wildcards, without a need for any new
> procedures/encodings

But with a lot more control plane messaging. If we know we're using 
BIER, we can optimize by eliminating a whole bunch of S-PMSI A-D routes, 
but that does require some new procedures/encodings.

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Wed, 7 Jan 2015 15:01:29 +0000

Eric,

inline

>particular (C-S,C-G) flow, the ingress PE must originate a (C-S,C-G)

Not necessarily. If, for example, Source PE wants to know of all (C-S,
C-G)s, it would simply send explicit tracking for (C-*, C-*), that would
make the receiver to respond with ALL (C-S, C-G)s that would match this
wildcard S-PMSI (which for BIER would do what you are looking at).

>receive a Leaf A-D route for each (C-S,C-G).

That is exactly how general (C-*, C-*) tracking works based on draft
clarifying 6513/6513/6625.
>but that does require some new procedures/encodings.

This does not apply, based on my above explanation.

Andrew

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 7 Jan 2015 15:06:30 +0000

Andrew,

> clarifying 6513/6513/6625.

Perhaps we missed it, but if that draft is just "clarifying" 6513/6514/6625, then you would not send individual (C-S,C-G) Leaf AD routes if you did not receive corresponding S-PMSI AD routes.

If that draft did say that, then it is no longer just a "clarifying" draft.

Jeffrey

> From: BIER [mailto:[email-masked]] On Behalf Of Dolganow, Andrew
> (Andrew)
> Sent: Wednesday, January 07, 2015 10:01 AM
> To: Eric Rosen; BIER
> Subject: Re: [Bier] Optimized explicit tracking for BIER
> 
> Eric,
> 
> inline
>

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Wed, 7 Jan 2015 15:14:13 +0000

Jeff,

What the draft say is you say individual Leaf A-D route if that route
would match the received S-PMSI A-D wildcard route for data transmission
based on 6625 procedures - see procedures on Receiver PE for wildcard
processing in the draft - maybe they need some more text or clarification?

Andrew

On 2015-01-07, 10:06 AM, "Jeffrey (Zhaohui) Zhang" wrote:

>Perhaps we missed it, but if that draft is just "clarifying"
>6513/6514/6625, then you would not send individual (C-S,C-G) Leaf AD
>routes if you did not receive corresponding S-PMSI AD routes.
>

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 7 Jan 2015 10:23:39 -0500

[Andrew] That is exactly how general (C-*, C-*) tracking works based on
draft clarifying 6513/6513/6625.

I certainly did not get that from your draft.  (I still don't see it in 
your draft.)

[Jeffrey] Perhaps we missed it, but if that draft is just "clarifying"
6513/6514/6625, then you would not send individual (C-S,C-G) Leaf AD
routes if you did not receive corresponding S-PMSI AD routes.

I agree with Jeffrey; existing procedures from RFCs 6514/6625 do not 
cause multiple Leaf A-D routes to be sent in response to a single S-PMSI 
A-D route.  If we want this to happen, we do need to modify some of the 
procedures and encodings.

In particular, if one sends a (C-*,C-*) S-PMSI A-D route with LIR set, 
one can expect to get back a (C-*,C-*) Leaf A-D route.  If one wants to 
get back multiple (C-S,C-G) Leaf A-D routes instead, one needs to use a 
flag other than LIR.

Also, the RFC6514 procedures generally assume that when one receives a 
Leaf A-D route, its "route key" field will be identical to the NLRI of 
some S-PMSI A-D route that one has originated.  The only exception to 
this is in the global table multicast procedures of 
draft-ietf-mpls-seamless-mcast.  Use of this sort of procedure in MVPN 
is new.

Fortuitously, it does seem like we are on the same page about what 
should happen, even if we haven't yet agreed on all the details of how 
to make it happen ;-)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 7 Jan 2015 15:27:24 +0000

Andrew,

I read that draft again, and the closest to what you're saying below is the following:

3.1. S-PMSI A-D route without tunnel information

   This case applies when S-PMSI A-D route does not exist OR S-PMSI A-D
   route's Multicast Source and Multicast Group fields do not encode the
   stream to be tracked.

   ... Tunnel Type field set to "No tunnel information".

However the following section does not talk about it at all:

4.1.1. S-PMSI A-D route without tunnel information

Besides, in Eric's email, a different flag bit is used, and the tunnel type field can be a valid tunnel type istead of "no tunnel info".

Additionally, section 4.2 does not really say that individual (C-S,C-G) Leaf AD routes will be originated. I read it as corresponding wildcard Leaf AD routes would be originated.

Even if the intention is indeed to originate individual (C-S,C-G) Leaf AD routes, then definitely more text is needed, and we must not rely on the "no tunnel info". Instead, a separate indication is needed.

Jeffrey

> From: Dolganow, Andrew (Andrew) [mailto:andrew.dolganow@alcatel-
> lucent.com]
> Sent: Wednesday, January 07, 2015 10:14 AM
> To: Jeffrey (Zhaohui) Zhang; Eric Rosen; BIER
> >> >> The above draft clarifies things up and allows explicit tracking
> for
> >> any

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 7 Jan 2015 10:44:43 -0500

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?

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Wed, 7 Jan 2015 15:47:50 +0000

Let¹s say the Sender sends S-PMSI A-D (C-*,C-*) route without or with
tunnel info (which will be BIER for BIER). I am including what I think
would apply to BIER (wildcard request with Leaf info required flag set and
BIER ³tunnel² encoded an dput ³Š² for non-applicable text):

4.2:

PE receiving S-MPSI A-D route with tracking request, performs procedures
defined in section 12.3 of [MVPN-NG] either ... or as consequence of
procedures of section 4 of [MVPN-WC] for wildcard stream tracking request
with the following modifications:

1. ...

2. If a PE determines that it no longer is to receive traffic for an
explicitly tracked multicast stream from the PE that originated explicit
tracking for that streams, the PE MUST withdraw the Leaf A-D route
originated in response to explicit tracking using standard procedures
defined in [MVPN-BGP]. - could apply
3. If a PE determines that it is to receive traffic for an explicitly
tracked multicast stream from the PE that originated explicit tracking for
that streams, the PE MUST re-originate a Leaf A-D route as defined in
[MVPN-BGP]. - this will cause the Leaf A-D per (C-S, C-G) as on Receiver
those would map to (C-*, C-*) wildcard (S-PMSI as per procedures of
RFC6625.

Andrew

On 2015-01-07, 10:27 AM, "Jeffrey (Zhaohui) Zhang" wrote:

>Besides, in Eric's email, a different flag bit is used, and the tunnel
>type field can be a valid tunnel type istead of "no tunnel info".
>
>Additionally, section 4.2 does not really say that individual (C-S,C-G)
>Leaf AD routes will be originated. I read it as corresponding wildcard
>Leaf AD routes would be originated.
>
>Even if the intention is indeed to originate individual (C-S,C-G) Leaf AD
>routes, then definitely more text is needed, and we must not rely on the
>"no tunnel info". Instead, a separate indication is needed.
>
>Jeffrey
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 7 Jan 2015 15:56:40 +0000

> tracked multicast stream from the PE that originated explicit tracking
> for that streams, the PE MUST re-originate a Leaf A-D route as defined in

While a particular (C-S,C-G) maps to a (C-*,C-*) wildcard, the text does not say individual (C-S,C-G) Leaf AD routes will be originated. The 6514/6625 procedures say (C-*,C-*) Leaf AD route will be originated.

Anyway, as Eric said, we're now on the same page wrt triggering (C-S,C-G) Leaf AD w/o requiring corresponding S-PMSI AD route. More text and encoding are needed to complete that.

Jeffrey

> Sent: Wednesday, January 07, 2015 10:48 AM
> >> >> >> I find the below procedure thus duplicate of what we already
> have
> >> on
> >> >> >ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each
> flow.
> >> >> It
> >> >> >originates a single (C-*,C-*) S-PMSI A-D route, and this causes
> it
> >> to

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Wed, 7 Jan 2015 16:07:17 +0000

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

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 8 Jan 2015 11:00:09 -0500

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

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

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

> We probably should then bring this discussion to BLESS.

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

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Thu, 8 Jan 2015 18:38:38 +0000

Great thanks.

Andrew

Sent from my iPhone

> On Jan 8, 2015, at 11:00 AM, Eric C Rosen <[email-masked]> wrote:
> 
> I think we are in agreement here, but for clarity we need to distinguish between two different things:
> 
> - 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.
> 
>>