Re: [Bier] Zaheduzzaman Sarker's No Objection on draft-ietf-bier-te-arch-10: (with COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

We are all good here, I have now a better understanding and thanks for addressing my comments.

BR
Zahed

> On 28 Jan 2022, at 18:06, Toerless Eckert <[e-mail]> wrote:
> 
> Thanks, Zaheduzzaman 
> 
> Detailed replies for your comments below inline. It should resolve all your concerns.
> These have been integrated into draft rev -12.
> 
> Full diff from -11 to -12:
> 
> http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-11.txt&url2=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-12.txt <http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-11.txt&url2=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-12.txt>
> 
> Diff with just the deltas for your comments:
> 
> http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/toerless/bier-te-arch/8ed27af30d4da5883aeab7d63a2c427fa2922b1a/draft-ietf-bier-te-arch.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/c88c22d82f8e17e66929e2f0d82ca02680b8fe0e/draft-ietf-bier-te-arch.txt <http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/toerless/bier-te-arch/8ed27af30d4da5883aeab7d63a2c427fa2922b1a/draft-ietf-bier-te-arch.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/c88c22d82f8e17e66929e2f0d82ca02680b8fe0e/draft-ietf-bier-te-arch.txt>
> 
> Thanks again for your review.
> 
> Toerless
> 
> 
> On Thu, Aug 26, 2021 at 05:15:48AM -0700, Zaheduzzaman Sarker via Datatracker wrote:
>> Zaheduzzaman Sarker has entered the following ballot position for
>> draft-ietf-bier-te-arch-10: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Thanks for the efforts on this document. Due to lack of time on my side
>> (apologies) I quickly read through the document and didn't find any transport
>> related issue sticking out. I agree with TSVART reviewer (Thanks Tommy Pauly)
>> that this seems useful to reduce duplicate packets to avoid unnecessary effects
>> in the higher layers.
>> 
>> I have two clarification questions:
>> 
>> * Section 5.3.6.2: if there is 6 SIs in the example then why does the it loops
>> through only 5 of them? see the text below -
>> 
>>    On all area edge BFR, bea in
>>   BIFT:SI=k|k=2...6 is populated with forward_routed(BFRka) and beb in
>>   BIFT:SI=k with forward_routed(BFRkb).
>> 
>>   For BIER-TE forwarding of a packet to a subset of BFERs across all
>>   areas, a BFIR would create at most 6 copies, with SI=1...SI=6,
> 
> The explanation was the last sentence in the paragraph:
> 
> | For this setup we do not consider area 1 because we assume the BIER-TE
> | setup is just for sending traffic from area 1 into area 2...6,
> | for example bcause the broadcast headends are in area 1 for an IPTV BIER-TE setup.
> 
> But i think i was confused here and optimized to much and made it inconsistent
> with the rest of the text. So i removed that sentence and changed the ranges to ..=1...6
> Thanks!
> 
>> * This might be completely my misunderstanding, however, I understood that
>> BIER-TE supports multiple domains and subdomains, where multiple domains may
>> not be under same implementer.
> 
> Domains and Subdomains are primarily operator related. A Domain belongs to
> one (potentially federated/orchestrated) operator, subdomains are just
> a way within a domain to scale and to enable different modes, such as
> running BIER and BIER-TE in parallel.
> 
>> In that case, would their not be issues for
>> BIER-TE controllers to show robust behavior if there is no default ECMP
>> algorithm?
> 
> Remember that ECMP is used in IP unicast since the inception of IP,
> and AFAIK, we never standardized an ECMP algorithm. I did have a good amount
> of encounter with multi-vendor IP networks and multiple ECMPs being used,
> and it always was some amount of pain, but primarily to the point of
> getting documentation for the algorithms so that one could calculate/plan
> traffic flows. Hence i choose here in this architecture spec to only
> define the framework for BIER-TE ECMP and mandate documentation.
> If there is interest in a standardized ECMP algorithm, we can easily do
> this as a followup spec.
> 
> Anothre reason for not wanting to demand a particular algorithm was that
> in the context of IP multicast we revisited a few and got good measurement
> feedback only years later (complaining about what we felt to be good to
> not be so good in the end). Meaning that if we wanted to do this, it might
> be something to take its own timeline as an RFC.
> 
>> Also the implementer is expected to document their ECMP of choice, I
>> didn't understand in what format and to who the documentation applies.
> 
> I did improve the relevant text in the section including to add the statement,
> that the example ECMP algorithm shown is represented in a form sufficient
> to serve as documentation.
> 
>> Also there is no discussions on what happens if there is no such documentation.
> 
> Yes. Unfortunately?, we do not have an IETF inquisition department
> for bad implementers. But that too is not new for this - not even normative -
> requirement.
> 
> Thanks again
>    Toerless