Alia, We have absolutely concrete requirement to support BEIR over IGP Algorithm (including Flex Algo). As such Option- E have been the most viable approach for me. However, based on continues discussions and in my view unsubstantiated/aspiring requirements in regards to define its own algorithm for BEIR future proof flexibility, I have tended to agree to have a right placeholder for IGP Algorithm and Bier Algorithm specified by BIER Info sub-TLV. It would be interesting to hear other operators use cases to convert aspiring requirements to tangible ones. As part of small group from members of BIER WG, we did not have much time to discuss in details interworking option between Bier Algo and IGP Algo and since of the time pressure related to the Last Call deadline, I opened debate within BIER WG to extend current BAR field to 16bits to have enough bits to accommodate any solution that suits the relevant use-cases best in an orthogonal fashion. That is one of the variation of proposed Option-C, just to have a placeholder and then figure out details.
I personally struggle how to achieve deterministic behavior as part of interworking between Bier and IGP algo. Each of the Algos defines its own set of constraints/computations over a given topology, which leads to dilemma how to reflect via specific code points a desirable constraint/computation combination. To get a better grasp of this interworking , I created a flow chart that I can share with the WG in pdf format if it is acceptable. Below I depicted a few combinations assuming dedicated 1B fields for BAR and FA in Bier info sub-TLV to show the complexity of the problem that we need to solve: Legend: FA-IGP/Flex Algo; BAR- Bier Algo . My apology to the folks that already saw it, but I believe it is important to show it. 1. BIER fully relies on IGP Algo - FA has full control ( constraints/computation) if BAR =0 and FA=X ( where X any value from 0-255) Solution: BAR=0, FA=0 covered by bier-isis draft, all other use cases such as BAR=0, FA!=0 by new draft. 2. BIER fully relies on BAR- BAR has full control ( constraints /computation) if BAR = X (where X any value from 1-255) with FA=0. Solution: BAR!=0, FA=0 Covered by new draft ( example proposed BAR1 as part of bier-algorithm draft should be supported with no issues) 3. BIER relies on - FA has full constraints control, BAR full computation (Any topology constraints defined by BAR ignored, Any computation defined by FA ignored). NO SOLUTION: Interesting to understand which BAR, FA combination can achieve it? ( how to distinguish topology from computation based on value of BAR1 or FA1?) 4. BIER relies on - BAR has full constraints control, FA full computation. (Any topology constraints defined by FA ignored, Any computation defined by BAR ignored). NO SOLUTION: Interesting to understand which BAR, FA combination can achieve it? ( how to distinguish topology from computation based on value of BAR1 or FA1?) 5. BIER relies on - FA & BAR constraints bundle for overall topology (BAR on top of FA), and BAR has full computation algorithm control (Any computation defined by FA ignored). NO SOLUTION: As example, this covers use case for BAR1 over FA for Excluding BIER incapable nodes. So proposed BAR1 defines the following exclude constraint: to prune any nodes that do not support <SD,MT,BAR,ENC,BSL>, it also defines computation algo: SPF; so now assume FA1 defines topology constraints as well and SPF as computation algo. So which attribute will trigger to ignore FA computation?. 6. BIER relies on - FA & BAR constraints bundle for overall topology(BAR on top of FA), and FA has full computation algorithm control (Any computation defined by BAR ignored). NO SOLUTION: Similar to the case above, but in this case dilemma is which attribute will define to ignore BAR computation? I mentioned a few times a bier-algorithm draft that just got released by Jeffrey, the draft solve the issue of EXCLUDING BIER INCAPABLE NODES. Just for reference, FA registry as part of Option-E can solve this problem as well with no major compromises. I also want to point out that from above use cases may be it is not so obvious, but you can derive that BAR is not just complements IGP algorithm it is actually in competition with given underlay that provides underlay functions for BIER. It is nice when operators have a choice, as long as it can be deterministic. Scenarios above might be viable or not, as such it is important to define the scope which use cases we are trying to solve. So back to proposed options. I personally like Eric proposed option -two independed 1Byte filed one for IGP Algo and another one for BUAM : the "BIER Underlay Algorithm Modifier" registry. The way the underlay paths are computed for a given BIER sub-domain is determined by the pair of codepoints: <IGP Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>. Not sure why it is not in a list of proposed options since I saw a lot of support for it on the WG. It sort of Option-B but allow more independence between BAR(BUAM) from IGP Algo, which personally attracts me since one cannot screw up another one and at the same time complement each other as part of constraints only. It might lock thing out for future development but it might bring stability. But regardless, we need to understand which use cases we are trying to cover and how the proposed option-B will apply. I would reiterate your request for specific recommendation for the draft from folks that recommend option B. Thanks Arkadiy From: BIER <[email protected]> on behalf of Alia Atlas <[email protected]> Date: Tuesday, February 20, 2018 at 12:03 PM To: BIER WG <[email protected]> Cc: "[email protected] list" <[email protected]> Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions Thanks for the feedback. There is one additional aspect here that I think needs further clarification and discussion. In the current proposed charter, the first work-item says "Operation of BIER in non-congruent topologies, i.e. topologies where not all routers are BIER capable can also be addressed." The newly posted individual draft-zzhang-bier-algorithm-00 suggests having an algorithm which is doing an SPF after removing from the topology any non-BIER capable routers. This is an example of a BIER-specific constraint. The individual flex-algo drafts also support adding constraints (similar to the familiar constraints from RSVP-TE). I believe that the need for BIER-specific constraints is one factor driving the requirement for a BAR that is specified by the BIER WG. From an architectural view, the idea of having the IGP/routing layer have to understand BIER specifics seems an undesirable coupling. Could someone walk me through how this would be supported in each of the different options? For Option D, where there is a sub-TLV and that sub-TLV can supply the additional non-BIER constraints, I understand it. For Option B - which some folks are preferring, I do not see understand how it would work. For Option A, I do not understand how it would work. Obviously, this is going far out on a design limb - where flex-algo does not yet have any IETF support or adoption, but since it is clear that people's perspectives are being strongly influenced by what that might morph into, I think this is important for the whole WG to understand. Regards, Alia On Tue, Feb 20, 2018 at 10:37 AM, Tony Przygienda <[email protected]<mailto:[email protected]>> wrote: all the implementations I am aware off can adjust to Option A) with BAR registry without problems, neither do I see a problem with option B) given we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas <[email protected]<mailto:[email protected]>> wrote: I have one additional question for those with implementations or testing them. What is the impact of going with your preferred option in terms of interoperability? It may be early enough that changes can happen, but more feedback is needed. For those favoring Option B, could you send email to the list providing exact text so we have the details? For those favoring the current status without an IANA registry, are you able to handle one being imposed during IESG Review? It is an obvious concern to raise. Are you just prolonging or postponing the discussion? Regards, Aka On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" <[email protected]<mailto:[email protected]>> wrote: +1 to Option-B Seems future proof to me. Thanks, Senthil From: BIER [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Alia Atlas Sent: 20 February 2018 03:21 To: BIER WG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> list <[email protected]<mailto:[email protected]>> Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and draft-ietf-bier-ospf-extensions-12, I have been following the discussion on the mailing list with interest. I have not seen clear consensus for any change. Let me be clear on what I see the options are from the discussion. Then I'll elaborate a bit on how you can express your perspective most usefully. 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, only value 0 is specified. The drafts do not have an IANA registry - with the expectation that one will be created when the first additional use is clear. It is possible that there will be objections from the IESG to progressing without an IANA registry. Given the lack of clarity for future use-cases and after discussion, I decided not to force one after my AD review - but I will not push back against having a BIER IANA registry if raised by others. 2) Option B: Add a BAR sub-type of 8 bits. This would modify the current TLVs. Define an IANA registry for the BAR type. The meaning of the BAR sub-type derives from the BAR type. We can debate over the registration policy for the BAR type. 3) Option C: Change the BAR field to be 16 bits and define an IANA registry. Part of the range can be FCFS with Expert Review, part can be Specification Required, and part can be IETF Consensus. 4) Option D: At some point in the future, if there is an actual understood and documented need, a BAR sub-type could be added a sub-TLV. The length of the BAR sub-type could be determined when the sub-TLV is defined. Given a) option D exists b) there is currently only one defined value for BAR c) I do not see strong consensus for change to one particular other option I see no current reason for a change and I certainly see absolutely no reason for a delay in progressing the documents. I do want to be clear about what the WG wants to do on this issue. Therefore, here is my following request. Please send your feedback to the mailing list as follows: IF you prefer or can accept the current status, please say so. No more justification or reasoning is required. I just don't want the bulk of folks who are content to be overlooked by those suggesting change. IF you prefer or can accept the current status, but think there should be an IANA registry as is usual for managing code-points, please say so. No more justification is needed. IF you prefer Option B, C, and/or D, please say so with your explanation. More technical depth than "'we might need it" would be helpful; the availability of sub-TLVs already provides future proofing. IF you have a clear technical objection to why the Current Status is not acceptable, please express that - with clear details. IF you feel that additional code-points should be allocated in a BAR IANA Registry or have thoughts on the appropriate policy, please say so with your explanation for what those should be. Unless I see clear and strong consensus for something other than the Current Status, that will remain. IF there is clear and strong consensus for Option B, C, or D, or adding an IANA registry with particular values, then it will be possible to have a change up through this Weds night - with a 1 week WGLC on that particular technical change. My priority is to have the base BIER specifications published as Proposed Standards so that more BIER implementations and deployment can be done. I would like the WG to wrap up the core work (as expressed in the proposed recharter) so that you all can look at how to use it. Given this topic was raised last Weds and given that there are no technical objections raised to the documents as are, there isn't much time - so please just respond to this email ASAP. My deadline for a decision is 6pm EST on Weds. Regards, Alia _______________________________________________ BIER mailing list [email protected]<mailto:[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=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=cYIkQCWXJi27_weFtXfbTtRIxqKfBB7CnvKYIxKUb40&s=To9sNa0hNd54cgx-5K9J1xzffDoDHgUVMvuHsZvJnLY&e=>
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
