Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas <[e-mail]>]

Hi Jeffrey,

Yes, I was rushing & may have mangled the terminology in the final bit.

The routing layer 8-bit field can be from the IGP Algorithm registry.

Thanks for catching it & for your willingness to write this up more clearly!

Regards,
Aka

On Feb 21, 2018 10:05 AM, "Jeffrey (Zhaohui) Zhang" <[e-mail]>
wrote:

> Hi Alia,
>
>
>
> Thanks for articulating it very clearly, and bring out the issue of having
> a clear specification on the interaction.
>
>
>
> I need one clarification from you though – is it possible that the you
> actually meant BART when you said BARM, and vice versa, in the following?
>
>
>
> ------------------
>
> With that, the BART can be exactly the IGP Algorithms registry.
>
> All the IGP Algorithms are available.   For the 2 currently defined, the
> constraints are empty.
>
>
>
> For the BARM, all the necessary constraints can be applied first.
>
>
>
> To define a code-point for BARM, the following information is necessary:
>
>    i) Constraints
>
>    ii) Can constraints be additive  (default yes unless specified
> otherwise)
>
>    iii) What is the algorithm - or is it "empty"
>
> -------------
>
>
>
> I’ll try to work with Les on the text to specify the interaction.
>
>
>
> Jeffrey
>
>
>
> *From:* Alia Atlas [mailto:[e-mail]]
> *Sent:* Wednesday, February 21, 2018 9:45 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* IJsbrand Wijnands (iwijnand) <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail]; IJsbrand Wijnands <[e-mail]>; [e-mail]; Eric
> Rosen <[e-mail]>
> *Subject:* Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
> First, I greatly appreciate the rapid education I have gotten on why the
> different aspects of this are important.
>
>
>
> Let us explore some details on the plan for an 8-bit BART and an 8-bit
> BARM that are independent.  Jeffrey,
>
> I really appreciate your bringing this option to the list.  It simplifies
> the option B idea of subtypes away and there
>
> seems to be a good amount of interest in it.
>
>
>
> My concern is that we specify adequately how the codepoints in BART and
> BARM interact.
>
>
>
> One of the challenges with doing so has been, IMHO, a bit of terminology
> where we are describing these as
>
> algorithms but in fact these are tuples consisting of a set of constraints
> and a base algorithm.
>
>
>
> BART is the BIER layer's constraints (BC) and algorithm (BA).  Let us
> describe this as BART =  (BC, BA).
>
>
>
> BARM is the Routing layer's constraints (RC) and algorithm (RA).  Let us
> describe this as BARM = (RC, RA).
>
>
>
> Let me give some concrete examples.
>
>
>
> Consider a case of BART=4 which is known to mean (prune non-BIER routers,
> use SPF).
>
> BARM = 200, which is known to mean (prune links with BW <10G, use SPF)
>
>
>
> It is desirable to have an outcome that is (prune non-BIER routers and
> links with BW < 10G, use SPF).
>
>
>
> This can work algorithmically because the constraints are the types that
> we've seen before for RSVP-TE.
>
>
>
> What I think we need to make the independent 8-bit BART plus 8-bit BARM
> work is a clear specification
>
> of the interaction. I think that is:
>
>
>
> Start with the topology Topology.
>
> 1) Apply the constraints represented by the BART  BC(Topology)
>
> 2) Apply the constraints represented by the BARM  RC(BC(Topology))
>
> 3) Select the algorithm A as follows:  use BA or if BA is "empty", use RA.
>
>     Run A on RC(BC(Topology)) to get the next-hops and information for the
> BIFT.
>
>
>
> Key points on the algorithm aspect are:
>
> a) BIER is the higher layer, so it is assumed to know better which
> algorithm should be used.
>
> b) It is possible for BA to be "empty"  (as the BARM=0 case discussed) so
> that the algorithm
>
>     falls through to whatever is RA.
>
>
>
> With that, the BART can be exactly the IGP Algorithms registry.
>
> All the IGP Algorithms are available.   For the 2 currently defined, the
> constraints are empty.
>
>
>
> For the BARM, all the necessary constraints can be applied first.
>
>
>
> To define a code-point for BARM, the following information is necessary:
>
>    i) Constraints
>
>    ii) Can constraints be additive  (default yes unless specified
> otherwise)
>
>    iii) What is the algorithm - or is it "empty"
>
>
>
> I am bringing forth this description now because I am concerned that the
> interaction between
>
> BARM and BART is not adequately defined to be published - but I see the
> strong interest in
>
> this as the solution and, from my understanding of the problem, agree.
>
>
>
> Please comment ASAP.
>
>
>
> Jeffrey & Les, is this something that you can turn into clear text for the
> drafts?
>
>
>
> Regards,
>
> Alia
>
>
>
>
>
>
>
>
>
> On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang <
> [e-mail]> wrote:
>
> To make it absolutely clear using an example: even with <BART 1, BARM 200>
> it is still that the two fields are independent of each other.
>
> This particular combination means “apply BART 1” to “Flexible-Algo 200”,
> where “Flexible-Algo 200” could be “exclude red links”, while “BART 1”
> could be “skip BIER incapable routers”.
>
>
>
> This is a very practical and concrete example showing the advantage of
> having two separate fields. Other ways could be used to achieve the same
> result, but they’re more cumbersome.
>
>
>
> Jeffrey
>
>
>
> *From:* BIER [mailto:[e-mail]] *On Behalf Of *IJsbrand
> Wijnands (iwijnand)
> *Sent:* Wednesday, February 21, 2018 8:40 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; IJsbrand Wijnands <[e-mail]>;
> [e-mail] <[e-mail]>;
> Eric Rosen <[e-mail]>
> *Subject:* Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
>
>
>
>
> Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.
>
>
>
> Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0.
>
>
>
> Ice: Yes, sorry, I agree, BART is always BIER and BARM is always IGP.
>
>
>
> Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and
> v.s., if BART is used, BARM will just be 0.
>
>
>
> Thx,
>
>
>
> Ice.
>
>
>
>
>
> THx,
>
>
>
> Ice.
>
>
>
>
>
> Jeffrey
>
>
>
> Registry Algorithm a.k.a as BARM then ... Without this section we would be
> mandating that BARM is always an IGP algorithm or FA so basically it would
> mandate IGP
>
>
>
> Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the
> people on the list who are of the opinion that aligning with IGP is
> important.
>
>
>
> Algorithm registry as the only option to perform a calculation making BART
> possibly pretty much useless ... Having a registry being mapped 1:1 into
> another registry known
>
>
>
> Ice: I don't understand why you are saying this. If BARM is 0, BART is all
> yours. Its unfortunate that a large part of the discussion is dominated by
> perceived functionality in the form of BIER Algorithm, while there is no
> architecture draft that describes how it should work and no discussion has
> happen in any IETF meeting, which leaves us all guessing. I think Alia
> asked a very good question on the list regarding "constraints". It is not
> at all clear if BART is a Algorithm or a Constraint. I think from your
> response you're saying its both, which seems wrong IMO.. To me Alia's
> question is still open, but that that may be because I could not decipher
> the rest of your response.
>
>
>
> as identity makes them both them the same thing by another name.
>
> So, to get anywhere close to consensus let's get bit less creative maybe
> and stick to the four letters of the alphabet that the AD extended as a
> wide playing field and the WG seems to converge around ... Or otherwise
> stick to option F) unmodified and see who's
>
> interested in it unless you insist on creating an option G) ...
>
>
>
> Ice: Jeffrey brought option F to the list in order to discuss it, that is
> what we are doing, and that is how you can converge on a solution and reach
> consensus. That is better compared to a vote on an option and everybody
> walks away with a different interpretation of it.
>
>
>
> Thx,
>
>
>
> Ice.
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=-s4yYMmN1jlRwgyk02_2IFamu-k7K7di1WiwKt-AoeE&s=pJHykwbjl-mkz5oRRkXE6hjOs0tsiC1ucjQtr6-F-4k&e=>
>
>
>