Re: [Bier] [SPAM?] Optimized explicit tracking for BIER

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

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

On 2015-01-06, 11:11 AM, "Eric C Rosen" wrote:

>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?
>
>
>
>
>
>
>_______________________________________________
>BIER mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bier