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

[Toerless Eckert <[e-mail]>]

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

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

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