Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Neeraj Malhotra]

Hi,

Support adoption.

Thanks,
Neeraj

On Mon, Nov 13, 2023 at 3:51 AM Jeffrey (Zhaohui) Zhang  wrote:

> Hi,
>
> This email begins a two-week WG adoption and IPR poll for
> draft-sajassi-bess-evpn-ip-aliasing-09 (
> https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09
> ).
>
> Please review the draft and post any comments to the BESS working group
> list.
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not progress without answers from all the authors and contributors.
>
> If you are not listed as an author or a contributor, then please
> explicitly respond to the IPR poll only if you are aware of any IPR that
> has not yet been disclosed in conformance with IETF rules.
>
> This poll for adoption closes on Monday, 27th of November, 2023.
>
> Thanks.
> Jeffrey
>
> Juniper Business Use Only
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-unequal-lb-18

[Neeraj Malhotra]

Hi Dhruv,

Many thanks for the review. Will update the draft and respond by next week.

Thanks,
Neeraj

On Thu, Nov 16, 2023 at 3:01 AM Dhruv Dhody via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Dhruv Dhody
> Review result: Has Issues
>
> # RTGDIR review of draft-ietf-bess-evpn-unequal-lb-18
>
> Hello,
>
> I have been selected to do a routing directorate “early” review of this
> draft.
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
>
> The routing directorate will, on request from the working group chair,
> perform
> an “early” review of a draft before it is submitted for publication to the
> IESG. The early review can be performed at any time during the draft’s
> lifetime
> as a working group document. The purpose of the early review depends on the
> stage that the document has reached. As this document is
> post-working-group-last-call, my focus for the review was to determine
> whether
> the document is ready to be published.
>
> For more information about the Routing Directorate, please see
> https://wiki.ietf.org/en/group/rtg/RtgDir
>
> Document: draft-ietf-bess-evpn-unequal-lb-18
> Reviewer: Dhruv Dhody
> Review Date: 16 Nov 2023
> Intended Status: Standards Track
>
> ## Summary:
>
> The motivation for the draft is clear and described well. However, I have
> significant concerns about this document. It needs more work before being
> submitted to the IESG.
>
> ## Comments:
>
> ### General
>
> * Request the shepherd to make sure that there is a valid justification
> for 6
> authors. Better yet just make it 5 authors (you have 3 authors from the
> same
> affiliation and one author marked as editor)
>
> * Please follow the RFC style guide. For instance, the Introduction should
> be
> the first section as per -
> https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.1. The best would
> be to
> have a new Introduction section that briefly introduces the concept and
> change
> section 2 to "Motivation" or something like that.
>
> * Use of some words in all capital letters -  OR, ALL, NOT. This should be
> avoided so as not to confuse with RFC2119 keywords which have special
> meaning
> when in capital.
>
> * The documents should add references to relevant RFCs when talking about
> existing EVPN features.
> * IRB
> *
>
> ### Section 1
>
> * Please update the Requirements Language template to -
> 
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>"OPTIONAL" in this document are to be interpreted as described in
>BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>capitals, as shown here.
> 
> * Please add references for the terms where possible. Definitions such as
> "Egress PE" and "Ingress PE" refer to RT-1, RT-2, and RT-5 especially needs
> one. Also, can the local PE and Ingress PE be different?
>
> ### Section 4
>
> * Why SHOULD and not MUST in -
> 
> Implementations SHOULD support the default units of Mbps
> 
> * IMHO section 4.2 is better suited in the appendix
>
> ### Section 5
>
> * Section 5.1; Why SHOULD and not MUST?
> * Section 5.1; Consider adding the reasoning behind
> 
>EVPN link bandwidth extended community SHOULD NOT be attached to per-
>EVI RT-1 or to EVPN RT-2.
> 
> * Section 5.2; If the extended commuity is silently ignored, how would an
> operator learn about it? At least a requirement for a log should be added.
> *
> Section 5.2; How is the weighted path list computed when the normalized
> weight
> is in fractions i.e. L(1, 10) = 2500 Mbps and thus W(1, 10) = 2.5? I am
> guessing you assume it is an integer (same as BW Increment) but it is not
> stated.
>
> ### Section 6
>
> * The update procedure listed here "updates" other specifications. I
> wonder if
> this should be captured in metadata, abstract etc.
>
> * Section 6.3.1,
> * Change L(min) to Lmin t to not be conffused by L(i)
> * I am unsure of what you mean by "with PE(1) = 10, PE(2) = 10, PE(3)
> = 20"
> which later changes to "with PE(1) = 10, PE(2) = 10, PE(3) = 10" *
> Other
> documents do not use the word affinity, it was difficult for me to
> verify
> the affinity formula and I left that for the WG to verify for
> correctness.
> * Inconsistency between MUST and MAY -
> 
>Depending on the chosen HRW hash function, the affinity function MUST be
>extended to include bandwidth increment in the computation.
>
>affinity function specified in [EVPN-PER-MCAST-FLOW-DF] MAY be
>extended as follows to incorporate bandwidth increment j:
>
>affinity or random function specified in [RFC8584] MAY be extended as
>follows to incorporate bandwidth increment j:
> 
>
> * Section 6.4, asks to add a new bullet (f) in
>
> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-pref-df-13.html#section-4.1
> ; Note that there is already a bullet f there!
>
> ### Section 9
>
> * What should be the 

Re: [bess] Genart early review of draft-ietf-bess-evpn-unequal-lb-18

[Neeraj Malhotra]

Hi Mallory,

Many thanks for the review. Will update the draft and respond by next week.

Thanks,
Neeraj

On Thu, Nov 16, 2023 at 10:13 AM Mallory Knodel via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Mallory Knodel
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. Please resolve these
> comments along with any other comments you may receive.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-bess-evpn-unequal-lb
> Reviewer: Mallory Knodel
> Review Date: 16 Nov 2023
>
> Summary: This draft is basically ready for publication, but has nits that
> should be fixed before publication.
>
> Major issues: Section 3 as the Solution Overview seems out of step with the
> remaining sections in that it properly describes the relationships between
> 4, 5
> and 6, but it appears that 7-10 are additional over arching considerations
> that
> might benefit from being extracted from the discussion of direct solutions.
> Suggesting perhaps that 4, 5 and 6 be treated under the solution space,
> whereas
> the remaining substantive sections 7-10 be presented as additional
> considerations and tradeoffs but not direct descriptions of full solutions
> to
> the problems outlined in the introduction.
>
> Minor issues: Not all acronyms are properly expanded in order of their
> first-time use which hinders readability. Seems 12. Operational
> Considerations
> is superfluous and plenty of document dependencies also do not have this
> section.
>
> Nits/editorial comments: The focus of my review did not expose any
> nits/editorial comments though I believe there are some that have persisted
> across the various versions that I compared and I would encourage the
> authors
> to do a full copy edit ahead of IESG submission.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess