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" <[email protected]> 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:[email protected]] > *Sent:* Wednesday, February 21, 2018 9:45 AM > *To:* Jeffrey (Zhaohui) Zhang <[email protected]> > *Cc:* IJsbrand Wijnands (iwijnand) <[email protected]>; > [email protected] <[email protected]>; > [email protected]; IJsbrand Wijnands <[email protected]>; [email protected]; Eric > Rosen <[email protected]> > *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 < > [email protected]> 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:[email protected]] *On Behalf Of *IJsbrand > Wijnands (iwijnand) > *Sent:* Wednesday, February 21, 2018 8:40 AM > *To:* Jeffrey (Zhaohui) Zhang <[email protected]> > *Cc:* [email protected]; [email protected]; IJsbrand Wijnands <[email protected]>; > [email protected] <[email protected]>; > Eric Rosen <[email protected]> > *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 > [email protected] > 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=> > > >
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
