Subject: [Bier] Mixing BIER-capable and non-BIER-capable line cards in one node

From: Eric C Rosen <[email-masked]>
Date: Fri, 24 Apr 2015 11:34:23 -0400

The architecture draft has some procedures (section 6.9) to deal with 
the case where some nodes support BIER and some don't.

A related case not yet mentioned in the draft is the case where some 
nodes have a mixture of BIER-capable links and non-BIER-capable links. 
This could happen on a platform that contains some line cards that are
BIER-capable and some that are not.

If we want to handle this case, the IGP extensions will have to tell us
which links of a given BFR support BIER and which don't.

When applying the procedures of section 6.9, we'd have to treat a 
BFR-NBR as a non-BFR if our link to it is not BIER-capable.  We could 
still bypass it with a unicast tunnel to a BFR (or BFER) that is further 
downstream.  But note that the procedure of unicast-tunneling a BIER 
packet to a BFR further downstream assumes that the packet will arrive 
at the latter BFR over a BIER-capable link.  So when using a unicast 
tunnel to bypass a non-BIER-capable link, we'd have to make sure to 
choose, as the tunnel endpoint, a BFR all of whose links are 
BIER-capable.  In practice, this would require either that all the links 
of a BFER be BIER-capable (except for any links that lead out of the 
BIER domain), or else that the unicast tunnels be explicitly routed to 
avoid the non-BIER-capable links.

A different approach would be to use the multi-topology feature of the 
IGP to have a BIER-specific topology that excludes any non-BIER-capable 
links that are attached to BFRs.  This topology could then be used both 
for native BIER and for the unicast tunnels.  But the disadvantage is 
that it is rather heavyweight, and requires a way to ensure that the 
unicast traffic tunnels used by BIER also travel over the BIER-specific 
topology.

An intermediate approach would be to have a BIER-specific SPF 
computation that excludes the non-BIER-capable links attaching to BFRs, 
but does not require setting up the IGP multi-topology feature.  This is 
not as heavyweight.  However, either the unicast tunnel endpoints would 
have to be BFRs that contain only BIER-capable links, or some additional 
means of keeping the unicast tunnels off the non-BIER-capable links 
would be needed.

Thoughts?

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 24 Apr 2015 13:59:31 -0400

Hi Eric,

> An intermediate approach would be to have a BIER-specific SPF computation that excludes the non-BIER-capable links attaching to BFRs, but does not require setting up the IGP multi-topology feature.  This is not as heavyweight.  However, either the unicast tunnel endpoints would have to be BFRs that contain only BIER-capable links, or some additional means of keeping the unicast tunnels off the non-BIER-capable links would be needed.
> 
> Thoughts?

Trying to avoid hitting certain line cards that don’t support BIER can be pretty complicated. Its not just trying to avoid that ingress LC that does not support BIER, its also possible that (one or more) egress LC's don’t support BIER. It all depends how BIER is implemented in the specific platform. 

IMO, the right way to solve this problem is with multi-topology routing. The risk of doing an intermediate approach is that you still end up doing a lot of work while not solving all corner cases.

Thx,

Ice.

> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 24 Apr 2015 18:12:36 +0000

It's mainly a question whether we can convince an operator to deploy MT because of the partial support. Some may be fine while some others may want to avoid MT (whether that's justified is subjective).

If we had to address the problem w/o using MT, then advertising per-link capability on those partially capable BFRs is precisely to address the problem of avoiding egress LCs that do not support BIER (otherwise, a BFR could just redirect incoming BIER traffic from an incapable LC to a capable LC).

Jeffrey

> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands
> Sent: Friday, April 24, 2015 2:00 PM
> To: Eric Rosen
> Cc: BIER
> Subject: Re: [Bier] Mixing BIER-capable and non-BIER-capable line cards in
> one node
> 
> Hi Eric,
> 
> means of keeping the unicast tunnels off the non-BIER-capable links would
> be needed.
> >
> > Thoughts?
> 
> Trying to avoid hitting certain line cards that don’t support BIER can be
> pretty complicated. Its not just trying to avoid that ingress LC that does
> not support BIER, its also possible that (one or more) egress LC's don’t
> support BIER. It all depends how BIER is implemented in the specific
> platform.
> 
> IMO, the right way to solve this problem is with multi-topology routing.
> The risk of doing an intermediate approach is that you still end up doing
> a lot of work while not solving all corner cases.
> 
> Thx,
> 
> Ice.
> 
> >

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Fri, 24 Apr 2015 22:50:16 +0000

Jeffrey,

I think we should try avoid over-complicating out solution to deal with partial support cases. The beauty of BIER is that it is "simple" (in positive way). MT is a simple solution to the partial BIER support problem. 

Andrew

Sent from my iPhone

> On Apr 24, 2015, at 2:13 PM, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 25 Apr 2015 00:18:18 +0000

That's fine. Just wanted to bring up the issue.

Jeffrey

> From: Dolganow, Andrew (Andrew) [mailto:[email-masked]]
> Sent: Friday, April 24, 2015 6:50 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: IJsbrand Wijnands; Eric Rosen; BIER
> I think we should try avoid over-complicating out solution to deal with
> partial support cases. The beauty of BIER is that it is "simple" (in
> positive way). MT is a simple solution to the partial BIER support problem.
> 
> Andrew
> 
> Sent from my iPhone
> 
> > It's mainly a question whether we can convince an operator to deploy MT
> because of the partial support. Some may be fine while some others may
> want to avoid MT (whether that's justified is subjective).
> >
> > If we had to address the problem w/o using MT, then advertising per-link
> capability on those partially capable BFRs is precisely to address the
> problem of avoiding egress LCs that do not support BIER (otherwise, a BFR
> could just redirect incoming BIER traffic from an incapable LC to a
> capable LC).
> >
> > Jeffrey
> >
> >> Subject: Re: [Bier] Mixing BIER-capable and non-BIER-capable line
> >> cards in one node
> >>
> >> Hi Eric,
> >>
> >> computation that excludes the non-BIER-capable links attaching to
> >> BFRs, but does not require setting up the IGP multi-topology feature.
> >> This is not as heavyweight.  However, either the unicast tunnel
> >> endpoints would have to be BFRs that contain only BIER-capable links,
> >> or some additional means of keeping the unicast tunnels off the
> >> non-BIER-capable links would be needed.
> >>>
> >>> Thoughts?
> >>
> >> Trying to avoid hitting certain line cards that don't support BIER
> >> can be pretty complicated. Its not just trying to avoid that ingress
> >> LC that does not support BIER, its also possible that (one or more)
> >> egress LC's don't support BIER. It all depends how BIER is
> >> implemented in the specific platform.
> >>
> >> The risk of doing an intermediate approach is that you still end up
> >> doing a lot of work while not solving all corner cases.
> >>
> >> Thx,
> >>
> >> Ice.
> >>
> >>>