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

[Senthil Dhanaraj <[e-mail]>]

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) <
[e-mail]> wrote:

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