Subject: Re: [bmwg] bmwg Digest, Vol 200, Issue 6

From: "Sudhin" <[email-masked]>
Date: 17 Jun 2021 10:22:14 -0000

Hi Joel,

Thank you for the comments. Appreciate it. Kindly find the answers inline and the modification will be done shortly, I will update the new version in a couple of days.

Regards,
Sudhin

From: [email-masked]
Sent: Thu, 17 Jun 2021 00:31:11
To: [email-masked]
Subject: bmwg Digest, Vol 200, Issue 6

Send bmwg mailing list submissions to
&nbsp;&nbsp;&nbsp;[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
&nbsp;&nbsp;&nbsp;https://www.ietf.org/mailman/listinfo/bmwg
or, via email, send a message with subject or body &#39;help&#39; to
&nbsp;&nbsp;&nbsp;[email-masked]

You can reach the person managing the list at
&nbsp;&nbsp;&nbsp;[email-masked]

When replying, please edit your Subject line so it is more specific
than &quot;Re: Contents of bmwg digest...&quot;

Today&#39;s Topics:

&nbsp; 1. Rtgdir last call review of draft-ietf-bmwg-evpntest-08
&nbsp; &nbsp; &nbsp;(Joel Halpern via Datatracker)

----------------------------------------------------------------------

Message: 1
Date: Wed, 16 Jun 2021 11:59:12 -0700
From: Joel Halpern via Datatracker &lt;[email-masked]&gt;
To: &lt;[email-masked]&gt;
Cc: [email-masked], [email-masked],
&nbsp;&nbsp;&nbsp;[email-masked]
Subject: [bmwg] Rtgdir last call review of draft-ietf-bmwg-evpntest-08
Message-ID: &lt;[email-masked]&gt;
Content-Type: text/plain; charset=&quot;utf-8&quot;

Reviewer: Joel Halpern
Review result: Has Issues

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-name-version.txt
Reviewer: your-name
Review Date: date
IETF LC End Date: date-if-known
Intended Status: copy-from-I-D

Summary:
I have some minor concerns about this document that I think should be resolved
before publication.

Major Comments: N/A

Minor Comments:
&nbsp; &nbsp;Reading section 3.1 on the rate for learning addresses, I am left guessing
&nbsp; &nbsp;how the procedure is to be performed. &nbsp;The text references RFC 2889 section
&nbsp; &nbsp;5.8, but only for the meaning for the terms. &nbsp;The test procedure is clearly
&nbsp; &nbsp;different since that test relies on observing flooding. &nbsp;As best I can
&nbsp; &nbsp;guess, the test assumes that there is an observable (Netconf ? YANG ?)
&nbsp; &nbsp;variable that reports how many local MAC addresses the device under test
&nbsp; &nbsp;has learned. &nbsp;It would be good to be more explicit about that, if possible
&nbsp; &nbsp;pointing to the YANG module that defines the parameter to be observed.
&nbsp;A similar clarification would be helpful on section 3.2 (on control plane MAC
&nbsp;learning). It probably would be helpful if sections 3.3 and 3.4 then
&nbsp;referenced sections 3.1 and 3.2 respectively for what is being observed. This
&nbsp;probably applies to section 4 as well. &nbsp;If the same variables are to be used,
&nbsp;then a simple reference to the earlier description would seem to suffice.

Sudhin&gt;&gt;&gt;&gt; it must be generic because not all the evpn features are supported in Yang models and it is up to the user choice that is reason any specific ways to capture the data is omitted.

&nbsp;I believe that section 3.8 on high availability is intended to cause a switch
&nbsp;of traffic path from DUT to MHPE2. &nbsp; However, the text in that section never
&nbsp;refers to MHPE 2. &nbsp;It refers to switch of routing processor. &nbsp;It is possible
&nbsp;that this is intended to be a redundancy test within DUT. &nbsp;If so, it would
&nbsp;help to be more explicit, since as far as I know we do not standardize that
&nbsp;behavior.

I am left puzzled as to the need for MHPE2 in these tests. &nbsp;I assume there is
some obvious and simple reason for including it that I missed. &nbsp;Could you add
an explanation?

Sudhin&gt;&gt;&gt; MHPE2 is very much needed in multi homing scenario, it plays as a standby role in testing, sure will add an explnation in the section&nbsp; &quot;Test Setup Configuration&quot;.
Nits:
&nbsp; &nbsp;At the end of section 2, the text reads &quot;The X is used as variable...&quot;
&nbsp; &nbsp;Could you change that to &quot;The X below is used as a variable ...&quot;? &nbsp;I spent
&nbsp; &nbsp;some time looking backwards for the X.

Sudhin &gt;&gt;&gt;&gt; Sure

&nbsp;The equation at the end of section 3.9 (ARD / ND scaling) is somewhat
&nbsp;misleading. &nbsp;It uses the same v1, v2, ..vn in successive lines to implicitly
&nbsp;refer to the IPv4 measurements and the IPv6 measurements. &nbsp;It would be good
&nbsp;to name these separately, as obviously the same calculation can not produce
&nbsp;two different results.

Sudhin&gt;&gt;&gt; sure will change.

------------------------------

Subject: Digest Footer

_______________________________________________
bmwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg

------------------------------

End of bmwg Digest, Vol 200, Issue 6
************************************

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Jun 2021 09:53:11 -0400

Thank you Sudhin.  If the observations have to be generic, then could 
you at least say that this will be measured by observing the network 
management counters that the implementations has chosen to expose?  And 
maybe even note that this will likely need to be specific to the 
implementation as said coutners are not currently standardized?

Yours,
Joel

On 6/17/2021 6:22 AM, Sudhin wrote:
> Hi Joel,
> 
> Thank you for the comments. Appreciate it. Kindly find the answers 
> inline and the modification will be done shortly, I will update the new 
> version in a couple of days.
> 
> Regards,
> Sudhin
> 
> <https://www.ietf.org/mailman/listinfo/bmwg==>
> or, via email, send a message with subject or body 'help' to
>     [email-masked]
> 
>     [email-masked]
> than "Re: Contents of bmwg digest..."
> 
> 
> Today's Topics:
> 
>    1. Rtgdir last call review of draft-ietf-bmwg-evpntest-08
>       (Joel Halpern via Datatracker)
> 
> 
> From: Joel Halpern via Datatracker <[email-masked]>
> To: <[email-masked]>
>     [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> Reviewer: Joel Halpern
> <http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir==>
> 
>     Reading section 3.1 on the rate for learning addresses, I am left 
> guessing
>     how the procedure is to be performed.  The text references RFC 2889 
> section
>     5.8, but only for the meaning for the terms.  The test procedure is 
> clearly
>     different since that test relies on observing flooding.  As best I can
>     guess, the test assumes that there is an observable (Netconf ? YANG ?)
>     variable that reports how many local MAC addresses the device under test
>     has learned.  It would be good to be more explicit about that, if 
> possible
>     pointing to the YANG module that defines the parameter to be observed.
>   A similar clarification would be helpful on section 3.2 (on control 
> plane MAC
>   learning). It probably would be helpful if sections 3.3 and 3.4 then
>   referenced sections 3.1 and 3.2 respectively for what is being 
> observed. This
>   probably applies to section 4 as well.  If the same variables are to 
> be used,
>   then a simple reference to the earlier description would seem to suffice.
> 
> Sudhin>>>> it must be generic because not all the evpn features are 
> supported in Yang models and it is up to the user choice that is reason 
> any specific ways to capture the data is omitted.
> 
>   I believe that section 3.8 on high availability is intended to cause a 
> switch
>   of traffic path from DUT to MHPE2.   However, the text in that section 
> never
>   refers to MHPE 2.  It refers to switch of routing processor.  It is 
> possible
>   that this is intended to be a redundancy test within DUT.  If so, it would
>   help to be more explicit, since as far as I know we do not standardize 
> that
>   behavior.
> 
> I am left puzzled as to the need for MHPE2 in these tests.  I assume 
> there is
> some obvious and simple reason for including it that I missed.  Could 
> you add
> an explanation?
> 
> Sudhin>>> MHPE2 is very much needed in multi homing scenario, it plays 
> as a standby role in testing, sure will add an explnation in the section
> 
>   "Test Setup Configuration".
> 
> 
> Nits:
>     At the end of section 2, the text reads "The X is used as variable..."
>     Could you change that to "The X below is used as a variable ..."?  I 
> spent
>     some time looking backwards for the X.
> 
> Sudhin >>>> Sure
> 
>   The equation at the end of section 3.9 (ARD / ND scaling) is somewhat
>   misleading.  It uses the same v1, v2, ..vn in successive lines to 
> implicitly
>   refer to the IPv4 measurements and the IPv6 measurements.  It would be 
> good
>   to name these separately, as obviously the same calculation can not 
> produce
>   two different results.
> 
> Sudhin>>> sure will change.
> 
> 
> 
> 
> <https://www.ietf.org/mailman/listinfo/bmwg==>
> 
>

---

From: "Sudhin" <[email-masked]>
Date: 18 Jun 2021 03:09:35 -0000

Hi Joel,

Sure, I will put a note.

Regards,
Sudhin

From: &quot;Joel M. Halpern&quot; &lt;[email-masked]&gt;
Sent: Thu, 17 Jun 2021 19:23:29
To: &quot;[email-masked]&quot; &lt;[email-masked]&gt;
Cc: [email-masked]
Subject: Re: [RTG-DIR] bmwg Digest, Vol 200, Issue 6
&nbsp;iWe couldn&#39;t verify the sender of this email.Thank you Sudhin. &nbsp;If the observations have to be generic, then could
you at least say that this will be measured by observing the network
management counters that the implementations has chosen to expose? &nbsp;And
maybe even note that this will likely need to be specific to the
implementation as said coutners are not currently standardized?

Yours,
Joel

On 6/17/2021 6:22 AM, Sudhin wrote:
&gt; Hi Joel,
&gt;
&gt; Thank you for the comments. Appreciate it. Kindly find the answers
&gt; inline and the modification will be done shortly, I will update the new
&gt; version in a couple of days.
&gt;
&gt; Regards,
&gt; Sudhin
&gt;
&gt; From: [email-masked]
&gt; Sent: Thu, 17 Jun 2021 00:31:11
&gt; To: [email-masked]
&gt; Subject: bmwg Digest, Vol 200, Issue 6
&gt;
&gt; Send bmwg mailing list submissions to
&gt; &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]
&gt;
&gt; To subscribe or unsubscribe via the World Wide Web, visit
&gt; https://www.ietf.org/mailman/listinfo/bmwg
&gt; &lt;https://www.ietf.org/mailman/listinfo/bmwg==&gt;
&gt; or, via email, send a message with subject or body &#39;help&#39; to
&gt; &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]
&gt;
&gt; You can reach the person managing the list at
&gt; &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]
&gt;
&gt; When replying, please edit your Subject line so it is more specific
&gt; than &quot;Re: Contents of bmwg digest...&quot;
&gt;
&gt;
&gt; Today&#39;s Topics:
&gt;
&gt; &nbsp; &nbsp; 1. Rtgdir last call review of draft-ietf-bmwg-evpntest-08
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(Joel Halpern via Datatracker)
&gt;
&gt;
&gt; ----------------------------------------------------------------------
&gt;
&gt; Message: 1
&gt; Date: Wed, 16 Jun 2021 11:59:12 -0700
&gt; From: Joel Halpern via Datatracker &lt;[email-masked]&gt;
&gt; To: &lt;[email-masked]&gt;
&gt; Cc: [email-masked], [email-masked],
&gt; &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]
&gt; Subject: [bmwg] Rtgdir last call review of draft-ietf-bmwg-evpntest-08
&gt; Message-ID: &lt;[email-masked]&gt;
&gt; Content-Type: text/plain; charset=&quot;utf-8&quot;
&gt;
&gt; Reviewer: Joel Halpern
&gt; Review result: Has Issues
&gt;
&gt; I have been selected as the Routing Directorate reviewer for this draft. The
&gt; Routing Directorate seeks to review all routing or routing-related drafts as
&gt; they pass through IETF last call and IESG review, and sometimes on special
&gt; request. The purpose of the review is to provide assistance to the
&gt; Routing ADs.
&gt; For more information about the Routing Directorate, please see
&gt; ?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
&gt; &lt;http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir==&gt;
&gt;
&gt; Although these comments are primarily for the use of the Routing ADs, it
&gt; would
&gt; be helpful if you could consider them along with any other IETF Last Call
&gt; comments that you receive, and strive to resolve them through discussion
&gt; or by
&gt; updating the draft.
&gt;
&gt; Document: draft-name-version.txt
&gt; Reviewer: your-name
&gt; Review Date: date
&gt; IETF LC End Date: date-if-known
&gt; Intended Status: copy-from-I-D
&gt;
&gt; Summary:
&gt; I have some minor concerns about this document that I think should be
&gt; resolved
&gt; before publication.
&gt;
&gt; Major Comments: N/A
&gt;
&gt; Minor Comments:
&gt; &nbsp; &nbsp; &nbsp; Reading section 3.1 on the rate for learning addresses, I am left
&gt; guessing
&gt; &nbsp; &nbsp; &nbsp; how the procedure is to be performed. &nbsp; The text references RFC 2889
&gt; section
&gt; &nbsp; &nbsp; &nbsp; 5.8, but only for the meaning for the terms. &nbsp; The test procedure is
&gt; clearly
&gt; &nbsp; &nbsp; &nbsp; different since that test relies on observing flooding. &nbsp; As best I can
&gt; &nbsp; &nbsp; &nbsp; guess, the test assumes that there is an observable (Netconf ? YANG ?)
&gt; &nbsp; &nbsp; &nbsp; variable that reports how many local MAC addresses the device under test
&gt; &nbsp; &nbsp; &nbsp; has learned. &nbsp; It would be good to be more explicit about that, if
&gt; possible
&gt; &nbsp; &nbsp; &nbsp; pointing to the YANG module that defines the parameter to be observed.
&gt; &nbsp; &nbsp;A similar clarification would be helpful on section 3.2 (on control
&gt; plane MAC
&gt; &nbsp; &nbsp;learning). It probably would be helpful if sections 3.3 and 3.4 then
&gt; &nbsp; &nbsp;referenced sections 3.1 and 3.2 respectively for what is being
&gt; observed. This
&gt; &nbsp; &nbsp;probably applies to section 4 as well. &nbsp; If the same variables are to
&gt; be used,
&gt; &nbsp; &nbsp;then a simple reference to the earlier description would seem to suffice.
&gt;
&gt; Sudhin&gt;&gt;&gt;&gt; it must be generic because not all the evpn features are
&gt; supported in Yang models and it is up to the user choice that is reason
&gt; any specific ways to capture the data is omitted.
&gt;
&gt; &nbsp; &nbsp;I believe that section 3.8 on high availability is intended to cause a
&gt; switch
&gt; &nbsp; &nbsp;of traffic path from DUT to MHPE2. &nbsp; &nbsp;However, the text in that section
&gt; never
&gt; &nbsp; &nbsp;refers to MHPE 2. &nbsp; It refers to switch of routing processor. &nbsp; It is
&gt; possible
&gt; &nbsp; &nbsp;that this is intended to be a redundancy test within DUT. &nbsp; If so, it would
&gt; &nbsp; &nbsp;help to be more explicit, since as far as I know we do not standardize
&gt; that
&gt; &nbsp; &nbsp;behavior.
&gt;
&gt; I am left puzzled as to the need for MHPE2 in these tests. &nbsp; I assume
&gt; there is
&gt; some obvious and simple reason for including it that I missed. &nbsp; Could
&gt; you add
&gt; an explanation?
&gt;
&gt; Sudhin&gt;&gt;&gt; MHPE2 is very much needed in multi homing scenario, it plays
&gt; as a standby role in testing, sure will add an explnation in the section
&gt;
&gt; &nbsp; &quot;Test Setup Configuration&quot;.
&gt;
&gt;
&gt; Nits:
&gt; &nbsp; &nbsp; &nbsp; At the end of section 2, the text reads &quot;The X is used as variable...&quot;
&gt; &nbsp; &nbsp; &nbsp; Could you change that to &quot;The X below is used as a variable ...&quot;? &nbsp; I
&gt; spent
&gt; &nbsp; &nbsp; &nbsp; some time looking backwards for the X.
&gt;
&gt; Sudhin &gt;&gt;&gt;&gt; Sure
&gt;
&gt; &nbsp; &nbsp;The equation at the end of section 3.9 (ARD / ND scaling) is somewhat
&gt; &nbsp; &nbsp;misleading. &nbsp; It uses the same v1, v2, ..vn in successive lines to
&gt; implicitly
&gt; &nbsp; &nbsp;refer to the IPv4 measurements and the IPv6 measurements. &nbsp; It would be
&gt; good
&gt; &nbsp; &nbsp;to name these separately, as obviously the same calculation can not
&gt; produce
&gt; &nbsp; &nbsp;two different results.
&gt;
&gt; Sudhin&gt;&gt;&gt; sure will change.
&gt;
&gt;
&gt;
&gt;
&gt; ------------------------------
&gt;
&gt; Subject: Digest Footer
&gt;
&gt; _______________________________________________
&gt; bmwg mailing list
&gt; [email-masked]
&gt; https://www.ietf.org/mailman/listinfo/bmwg
&gt; &lt;https://www.ietf.org/mailman/listinfo/bmwg==&gt;
&gt;
&gt;
&gt; ------------------------------
&gt;
&gt; End of bmwg Digest, Vol 200, Issue 6
&gt; ************************************