Subject: [Bier] [BIER] Anycact BIER prefix and Conflict resolution

From: Senthil Dhanaraj <[email-masked]>
Date: Fri, 15 Feb 2019 13:00:35 +0530

Hi all,

How about any-cast prefix being used as BIER prefix ? Example,,

RTA ---(Prefix P1, SD=0, Bfrid=, ...)---
                                       |
                                       |--- RTC
                                       |
RTB ---(Prefix P1, SD=0, Bfrid=, ...)---

(Note: RTA,RTB could be a BFR or BFER.)

1) Procedures @RTC for constructing BIFT?
2) If the BIER parameters advertised by RTA and RTB are different, how RTC
should resolve the conflict ?
3) How an ABR should leak the prefix with BIER TLVs to other area in above
cases?

I think, it is better we bring out different cases and standardize the
procedure (say draft-bier-conflict-resolution) to be followed to ensure
deterministic network behavior. Kindly let me know what y'all think.

Thanks,
Senthil

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Fri, 15 Feb 2019 07:45:47 +0000

Hi Senthil,

I’m not convinced there is a conflict here.

If this is Anycast, there is still one prefix with one BFR-id assigned to it, so no conflict with that.

Router RTC will install the BEST path it has to prefix P1 in the BIFT, based on metric, distance, highest next-hop as tie breaker.

Thx,

Ice.

> On 15 Feb 2019, at 08:30, Senthil Dhanaraj <[email-masked]> wrote:
> 
> Hi all,
> 
> 2) If the BIER parameters advertised by RTA and RTB are different, how RTC should resolve the conflict ?
> 3) How an ABR should leak the prefix with BIER TLVs to other area in above cases?
> 
> I think, it is better we bring out different cases and standardize the procedure (say draft-bier-conflict-resolution) to be followed to ensure deterministic network behavior. Kindly let me know what y'all think.
> 
> Thanks,
> Senthil
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: Senthil Dhanaraj <[email-masked]>
Date: Fri, 15 Feb 2019 14:24:01 +0530

Hi Ice,

Few cases that i can quickly think of where-in the bier parameters
advertised by different routers with same prefix can be different.

1. Bad configuration
2. Hardware difference's b/w the routers (Encap, Bsl supported)
3. MPLS labels advertised by different routers for same SD/Bsl are almost
guaranteed not to be same.

Consider (3)
- The receiving BFR should accept both the advertisement and use the
corresponding MPLS label based on the router chosen as next hop.
- If both such routers are equi-cost, then both the routers should be
considered for ECMP BIFT and the corresponding labels should be used based
on the router chosen as next hop.

Consider (2)
- Accept both the advertisements. Include/Exclude routers from BIER SPF
based on BAR constraints (SD/BSL) or select nexthop based on the incoming
BIER packets encap/bsl?

Consider (1),
- Say bfr-id or sub-domain id could be different.
   Do not consider both the routers & raise alarm ? or Consider one router
based on some logic (say higher router-id wins)

I was thinking that we must clearly state & standardize the procedure to be
followed for such cases instead of leaving it to individual implementations
which in-turn may result in non-deterministic network behavior. Pls do let
me know your thoughts.

Thanks,
Senthil

On Fri, Feb 15, 2019 at 1:15 PM IJsbrand Wijnands (iwijnand) <
[email-masked]> wrote:

> Router RTC will install the BEST path it has to prefix P1 in the BIFT,
> based on metric, distance, highest next-hop as tie breaker.
>
> Thx,
>
> Ice.
>

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Thu, 21 Feb 2019 10:00:13 +0000

Hi Senthil,

> Few cases that i can quickly think of where-in the bier parameters advertised by different routers with same prefix can be different.
> 
> 1. Bad configuration
> 3. MPLS labels advertised by different routers for same SD/Bsl are almost guaranteed not to be same.
> 
> Consider (3)
> - The receiving BFR should accept both the advertisement and use the corresponding MPLS label based on the router chosen as next hop.
> - If both such routers are equi-cost, then both the routers should be considered for ECMP BIFT and the corresponding labels should be used based on the router chosen as next hop.

I think one way to solve that (typically used with Multicast), is to advertise one Prefix as /32 and the other as /31. That way you don’t load-balance over the two.

> Consider (2)
> - Accept both the advertisements. Include/Exclude routers from BIER SPF based on BAR constraints (SD/BSL) or select nexthop based on the incoming BIER packets encap/bsl?

I think the above solves this.

>    Do not consider both the routers & raise alarm ? or Consider one router based on some logic (say higher router-id wins)

This is also solved by /32 and /31 advertisement, no?

> I was thinking that we must clearly state & standardize the procedure to be followed for such cases instead of leaving it to individual implementations which in-turn may result in non-deterministic network behavior. Pls do let me know your thoughts.

I rather solve this problem with default RIB based mechanisms like Mask Length, distance and metric. I’m not convinced that doing this based on BIER specific information useful..

Thx,

Ice.

> 
> Thanks,
> Senthil 
> 
> On Fri, Feb 15, 2019 at 1:15 PM IJsbrand Wijnands (iwijnand) <[email-masked]> wrote:
> Hi Senthil,
>

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 25 Feb 2019 11:21:29 +0530

Hi Ice,

Sorry for the delayed response!

BIER Prefix MUST be associated with node address of the advertising node
(that is, prefix length MUST be 32 for IPv4). If the advertised BIER prefix
is not a node address (a.k.a length not equals 32), the BIER prefix will be
ignored by the receiving BFRs.

So, when you say "to advertise one Prefix as /32 and the other as /31. That
way you don’t load-balance over the two", Do you mean that, BIER
cannot/need-not support anycast prefix'es ? I think anycast is useful and
commonly used (redundancy/loadbalancing). Segment routing does support
anycast segments and it might be common that operators choose to share to
same (anycast/node) prefix for IGP/SR/BIER. No ?

Thanks,
Senthil

On Thu, Feb 21, 2019 at 3:30 PM IJsbrand Wijnands (iwijnand) <
[email-masked]> wrote:

> I think one way to solve that (typically used with Multicast), is to
> advertise one Prefix as /32 and the other as /31. That way you don’t
> load-balance over the two.
>
> > Consider (2)
> >    Do not consider both the routers & raise alarm ? or Consider one
> router based on some logic (say higher router-id wins)
>
> > I was thinking that we must clearly state & standardize the procedure to
> be followed for such cases instead of leaving it to individual
> implementations which in-turn may result in non-deterministic network
> behavior. Pls do let me know your thoughts.
>
> I rather solve this problem with default RIB based mechanisms like Mask
> Length, distance and metric. I’m not convinced that doing this based on
> BIER specific information useful..
>
> Thx,
>
> Ice.
>
>
> >
> > Thanks,
> > Senthil
> >

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Mon, 25 Feb 2019 13:50:54 +0000

Hi Senthil,

> BIER Prefix MUST be associated with node address of the advertising node (that is, prefix length MUST be 32 for IPv4). If the advertised BIER prefix is not a node address (a.k.a length not equals 32), the BIER prefix will be ignored by the receiving BFRs.

Yes that is a good point. I know BIER architecture RFC says that the BFR-Prefix must be an address, but, strictly speaking, the BFR-id must be associated with a Prefix. Maybe we need to think about how to relax this requirement of being an address.

> So, when you say "to advertise one Prefix as /32 and the other as /31. That way you don’t load-balance over the two", Do you mean that, BIER cannot/need-not support anycast prefix'es ? I think anycast is useful and commonly used (redundancy/loadbalancing). Segment routing does support anycast segments and it might be common that operators choose to share to same (anycast/node) prefix for IGP/SR/BIER. No ?

I think anycast is a good feature that we need to support in BIER. My thinking is that we could solve conflicts with different mask lengths as that gives a natural selection by using IGP selection criteria. Lets talk about this next IETF maybe?

Thx,

Ice.

> 
> Thanks,
> Senthil
> 
> 
> 
> On Thu, Feb 21, 2019 at 3:30 PM IJsbrand Wijnands (iwijnand) <[email-masked]> wrote:
> Hi Senthil,
>

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Mon, 25 Feb 2019 13:50:59 +0000

Hi Senthil,

Thx,

Ice.

---

From: Senthil Dhanaraj <[email-masked]>
Date: Tue, 26 Feb 2019 11:41:32 +0530

Hi Ice,

Im not convinced that we should relax the rule to bind bier with only node
prefix (32 length).
Even though, say we allow bier to be bound with non-node prefix'es, i do
not think we shall enforce a rule that "one MUST use anycast bier prefix'es
only with different lengths". We must allow sharing any existing anycast
node prefix'es in-use in the network (say SR anycast SID) for BIER as well.

But sure, lets catch up @IETF104 to discuss further.

Thanks,
Senthil

On Mon, Feb 25, 2019 at 7:21 PM IJsbrand Wijnands (iwijnand) <
[email-masked]> wrote:

> Yes that is a good point. I know BIER architecture RFC says that the
> BFR-Prefix must be an address, but, strictly speaking, the BFR-id must be
> associated with a Prefix. Maybe we need to think about how to relax this
> requirement of being an address.
>
> > So, when you say "to advertise one Prefix as /32 and the other as /31.
> That way you don’t load-balance over the two", Do you mean that, BIER
> I think anycast is a good feature that we need to support in BIER. My
> thinking is that we could solve conflicts with different mask lengths as
> that gives a natural selection by using IGP selection criteria. Lets talk
> about this next IETF maybe?
>
> Thx,
>
> Ice.
>
> >
> > Thanks,
> > Senthil
> >
> >
> >
> >> I was thinking that we must clearly state & standardize the procedure
> to be followed for such cases instead of leaving it to individual

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 26 Feb 2019 15:28:46 +0000

Hi Senthil,

Please see below:

Hi Ice,

1. Bad configuration

Consider (3)

<Nagendra> Based on the above, I am assuming that 2 BFRs advertises same BFR-id for same BFR-Prefix with same SI,BSL etc?. This is not different from how any BFR treats ECMP paths to same BFR-id.  When a BFR has ECMP paths to BFR-Prefix P and if the NH are different, it is expected to have different egress interface and different BIER-MPLS label. Anycast BIER Prefix will be treated the same way.

Consider (2)

<Nagendra> Section 6.10.2 of RFC8279 covers the forwarding semantic when there is BSL mismatch. But I think it is not clear about how to select/prefer when Anycast is advertised with different BSL. One option is to let a BFR prefer the Anycast with BSL matching the local/supported BSL. If nothing matches, follow section 6.10.2.

Consider (1),

<Nagendra> I think Section 5 may need some update to clarify that same BFR-id for same BFR-prefix can be received from different node and how to behave if we receive some mismatch.

Thanks,
Nagendra

On Fri, Feb 15, 2019 at 1:15 PM IJsbrand Wijnands (iwijnand) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Senthil,

Thx,

Ice.

> On 15 Feb 2019, at 08:30, Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi all,
>
> [email-masked]<mailto:[email-masked]>

---

From: Senthil Dhanaraj <[email-masked]>
Date: Wed, 27 Feb 2019 15:28:19 +0530

Hi Nagendra,

Agreed to all the comments from you and my responses inline !

Note:
- I would also like to understand Ice's suggestion on using different mask
lengths. So lets all catch up at IETF104 for a quick discussion.
- I think that the assumed/proposed methods to handle the below discussed
cases for anycast prefix is not implicitly clear via RFC8279 or by BIER LSR
extension RFCs (at least not to some of the implementer's i spoke to).
Hence posted in WG list to check if we need to make this clear by some way
(update existing rfc / new draft ..).

Thanks,
Senthil

On Tue, Feb 26, 2019 at 8:58 PM Nagendra Kumar Nainar (naikumar) <
[email-masked]> wrote:

> <Nagendra> Based on the above, I am assuming that 2 BFRs advertises same
> BFR-id for same BFR-Prefix with same SI,BSL etc?. This is not different
> from how any BFR treats ECMP paths to same BFR-id.  When a BFR has ECMP
> paths to BFR-Prefix P and if the NH are different, it is expected to have
> different egress interface and different BIER-MPLS label. Anycast BIER
> Prefix will be treated the same way.
>
Senthil2// Agreed and same is proposed in my text as well.

> <Nagendra> Section 6.10.2 of RFC8279 covers the forwarding semantic when
> there is BSL mismatch. But I think it is not clear about how to
> select/prefer when Anycast is advertised with different BSL. One option is
> to let a BFR prefer the Anycast with BSL matching the local/supported BSL.
> If nothing matches, follow section 6.10.2.
>
Senthil2// Agreed. To be more precise, assume BFR1(Prefix P1) advertise BSL
256 and BFR2(Prefix P1) advertises BSL128.
- Use the BAR algo (which specifies the constraints like SD/BSL/Encap) to
include a prefix/router in SPF. So BFR1/P1/BSL256 will be part of SPF tree
and BIFT table specific to BSL256 and BFR2/P1/BSL128 will be part of SPF
tree and BIFT table specific to BSL128. This way, based on the incoming BSL
of the packet at BFR (or based on the configured imposition BSL at BFIR),
corresponding SPT/BIFT will be used and the packet will be forwarded.

> <Nagendra> I think Section 5 may need some update to clarify that same
> BFR-id for same BFR-prefix can be received from different node and how to
> behave if we receive some mismatch.
>
Senthil2// Right. What do you prefer among the above two options?