Re: [Bier] Optimized explicit tracking for BIER

Eric,

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

Jeffrey

> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] 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
> 
> 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
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier