Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)

[Jorge Rabadan (Nokia)]

Thank you Warren.
Jorge

From: Warren Kumari 
Date: Friday, October 6, 2023 at 1:55 PM
To: Jorge Rabadan (Nokia) 
Cc: The IESG , draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 

Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with 
DISCUSS and COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.






On Fri, Oct 06, 2023 at 3:53 PM, Jorge Rabadan 
mailto:jorge.raba...@nokia.com>> wrote:
Hi Warren,

Thank you for reviewing.

We published version 12, which hopefully addresses most of the comments and 
discuss.

About why two algorithms:

Initially only highest-preference was defined and implemented, however, there 
was feedback from the Shepherd and others in the WG that defining the 
Lowest-Preference algorithm would provide more flexibility for the operator. 
For instance, the operator could define the same preference value for two 
Ethernet Segments in a PE1, but, by using highest-preference in ES1 and 
lowest-preference in ES2, we could achieve different DF election results per 
Ethernet Segmen and therefore have some DF distribution.


Urgh, that sounds very much like creeping featurism, but if the WG has 
consensus that the additional complexity is worth the win, then ¯\_(ツ)_/¯.

I hadn't considered the "if you set one high and one low you get DF 
distribution" aspect, nor did I see this explained in the doc (but perhaps I 
missed it).

It seems like it would be *mush* less confusing to just set the priorities how 
you want them, but…

It still all seems like needless additional operational complexity, but, if the 
WG has consensus on this, I'll clear…

W



Other than that, there is no difference between both, they are functionally 
equivalent. Only that one selects the highest value, and the other the lowest 
one.

Since the algorithm itself is signaled in the ES routes, and we explain how 
inconsistencies among PEs are handled, we think there is no additional 
complexity or risks.

If the above explanation is not enough, could you suggest any kind of text or 
guidance that could help clear your DISCUSS?

Thank you!
Jorge


From: Warren Kumari via Datatracker mailto:nore...@ietf.org>>
Date: Monday, August 7, 2023 at 3:55 PM
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-bess-evpn-pref...@ietf.org
 
mailto:draft-ietf-bess-evpn-pref...@ietf.org>>,
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Stephane Litkowski mailto:slitkows.i...@gmail.com>>, 
slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com>>
Subject: Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with 
DISCUSS and COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URLnok.it/ext for additional 
information.



Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
DISCUSS:
--

Why are there two algorithms (Highest-Preference and Lowest-Preference)?[0]
This seems operationally dangerous and will lead to additional operational
complexity, tricky to debug behaviors, additional implementation complexity,
etc. Assuming that there *is* a good reason (and "Well, we couldn't decide,,
so... ¯\_(ツ)_/¯" isn't one) these should be a section helping operators decide
which algorithm they should deploy, and the pro's and con's of each.

[0]: I did try and find this, but the closest I got was a note in the Shepherd
Writeup saying: "There was a "last minute" agreement on managing the
highest/lowest pref algorithm using different DF algs rather than a single
one+local configs." -- this doesn't actually answer the question.


--
COMMENT:
--

I support John Scudder's DISCUSS, as well as his comments -- the Introduction
seems quite incomplete, and just sort of throws the reader into the deep end.


___
BESS mailing list
BESS@ietf.org

Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[liu.yao71]

I support the WG adoption of this draft. It's an important update for RFC9252 
and benifits the implementation.

Regards,
Yao___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Shihang(Vincent)]

Hi,
I support the WG adoption.

Best,
Hang

From: BESS  On Behalf Of Matthew Bocci (Nokia)
Sent: Thursday, October 5, 2023 6:45 PM
To: bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

WG

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

Please review the draft and post any comments to the BESS mailing list.

This poll will close on Thursday 12th October.

Regards

Matthew

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network 
providers.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Gyan Mishra]

I reviewed the draft and it’s important updates to RFC 9252 to support SRV6
BGP service overlay to support SRv6 SID  ARG  field for endpoint behaviors
that require it namely with EVPN RT-1 and RT-3.

I support WG adoption.

Thanks

Gyan

On Thu, Sep 28, 2023 at 10:50 AM Matthew Bocci (Nokia) <
matthew.bo...@nokia.com> wrote:

> This email begins a two-week WG adoption and IPR poll for
> draft-trr-bess-bgp-srv6-args-02 [1].
>
>
>
> 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.
>
> Currently, there is currently no IPR disclosure against this document.
>
>
>
> 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 Thursday 12th October 2023.
>
>
>
> [1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP
> Services (ietf.org)
> 
> ___
> 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] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Voyer, Daniel]

I support the WG adoption of this draft.

Thanks
Dan

From: BESS  on behalf of "Matthew Bocci (Nokia)" 

Date: Thursday, September 28, 2023 at 10:49 AM
To: "bess@ietf.org" 
Cc: "draft-trr-bess-bgp-srv6-a...@ietf.org" 

Subject: [EXT][bess] WG adoption and IPR poll for 
draft-trr-bess-bgp-srv6-args-02

This email begins a two-week WG adoption and IPR poll for 
draft-trr-bess-bgp-srv6-args-02 [1].

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.
Currently, there is currently no IPR disclosure against this document.

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 Thursday 12th October 2023.

[1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP Services 
(ietf.org)
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)

[Warren Kumari]

On Fri, Oct 06, 2023 at 3:53 PM, Jorge Rabadan 
wrote:

> Hi Warren,
>
>
>
> Thank you for reviewing.
>
>
>
> We published version 12, which hopefully addresses most of the comments
> and discuss.
>
>
>
> About why two algorithms:
>
>
>
> Initially only highest-preference was defined and implemented, however,
> there was feedback from the Shepherd and others in the WG that defining the
> Lowest-Preference algorithm would provide more flexibility for the
> operator. For instance, the operator could define the same preference value
> for two Ethernet Segments in a PE1, but, by using highest-preference in ES1
> and lowest-preference in ES2, we could achieve different DF election
> results per Ethernet Segmen and therefore have some DF distribution.
>


Urgh, that sounds very much like creeping featurism, but if the WG has
consensus that the additional complexity is worth the win, then ¯\_(ツ)_/¯.

I hadn't considered the "if you set one high and one low you get DF
distribution" aspect, nor did I see this explained in the doc (but perhaps
I missed it).

It seems like it would be *mush* less confusing to just set the priorities
how you want them, but…

It still all seems like needless additional operational complexity, but, if
the WG has consensus on this, I'll clear…

W



>
> Other than that, there is no difference between both, they are
> functionally equivalent. Only that one selects the highest value, and the
> other the lowest one.
>
>
>
> Since the algorithm itself is signaled in the ES routes, and we explain
> how inconsistencies among PEs are handled, we think there is no additional
> complexity or risks.
>
>
>
> If the above explanation is not enough, could you suggest any kind of text
> or guidance that could help clear your DISCUSS?
>
>
>
> Thank you!
>
> Jorge
>
>
>
>
>
> *From: *Warren Kumari via Datatracker 
> *Date: *Monday, August 7, 2023 at 3:55 PM
> *To: *The IESG 
> *Cc: *draft-ietf-bess-evpn-pref...@ietf.org  ietf.org>, bess-cha...@ietf.org , bess@ietf.org <
> bess@ietf.org>, Stephane Litkowski , slitkows.
> i...@gmail.com 
> *Subject: *Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11:
> (with DISCUSS and COMMENT)
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URLnok.it/ext for additional
> information.
>
>
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-bess-evpn-pref-df-11: Discuss
>
> 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/about/groups/iesg/statements/
> handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/
>
>
>
> --
> DISCUSS:
> --
>
> Why are there two algorithms (Highest-Preference and Lowest-Preference)?[0]
> This seems operationally dangerous and will lead to additional operational
> complexity, tricky to debug behaviors, additional implementation
> complexity,
> etc. Assuming that there *is* a good reason (and "Well, we couldn't
> decide,,
> so... ¯\_(ツ)_/¯" isn't one) these should be a section helping operators
> decide
> which algorithm they should deploy, and the pro's and con's of each.
>
> [0]: I did try and find this, but the closest I got was a note in the
> Shepherd
> Writeup saying: "There was a "last minute" agreement on managing the
> highest/lowest pref algorithm using different DF algs rather than a single
> one+local configs." -- this doesn't actually answer the question.
>
>
> --
> COMMENT:
> --
>
> I support John Scudder's DISCUSS, as well as his comments -- the
> Introduction
> seems quite incomplete, and just sort of throws the reader into the deep
> end.
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

[Eric Vyncke (evyncke)]

Thank you, Jorge, for taking the time to reply.

I can only regret the use of “DP” rather than “DNP”, but you have a point if 
there are existing implementations.

Regards

-éric

From: Jorge Rabadan (Nokia) 
Date: Friday, 6 October 2023 at 21:51
To: Eric Vyncke (evyncke) , The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 

Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: 
(with COMMENT)
Hi Éric,

Thanks very much for the review. Your comments are addressed in version 12.

Please see in line with [Jorge] for more details.

Thanks.
Jorge

From: Éric Vyncke via Datatracker 
Date: Tuesday, August 1, 2023 at 2:35 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: (with 
COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-pref-df-11

Thank you for the work put into this document. Please note that I was close to
ballot a DISCUSS based on my non-blocking COMMENT points, but as I am not an
expert in EPVN, I am trusting the responsible AD.

Please find below osome non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and several nits (please run
your I-D through a spell-checker).
[Jorge] all the nits are fixed now, thanks


Special thanks to Stéphane Litkowski for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status even if
using the old template.

I hope that this review helps to improve the document,
[Jorge] it does, thank you very much.


Regards,

-éric

# COMMENTS

## Abstract

Please fix the expansion of BUM as it is not `Broadcast, Unknown unicast and
Broadcast traffic (BUM)` ;-)
[Jorge] fixed, thanks


## Section 1.1

Please fix the expansion of BUM as it is not `Broadcast, Multicast and Unknown
unicast traffic (BUM)` ;-) I was amused to read two different wrong expansions
for BUM ;-)
[Jorge] yeah, we should have caught it way earlier ☹ - It’s fixed now, thanks


I am sure that non SP will also use this technique, i.e., I wonder whether
s/Service Providers/Network Operators/ would be beneficial.
[Jorge] good point, changed now.


## Section 2

Rather than using "DP" in `DP - refers to the "Don't Preempt me"` should "DNP"
be more logical ?
[Jorge] maybe, but at this point with so many implementations (and debug 
commands showing DP), I prefer to keep it as DP. Hopefully it is ok.


## Section 3

Should RFC 8584 be formally updated as its reserved field is carved out ?

`The DP capability is supported by DF Algorithms Highest-Preference or
Lowest-Preference, and MAY be used with the default DF Algorithm or HRW
[RFC8584]` Is there any migration concern with the use of MAY ? I.e., part of
the participating routers will use the DP and the other part not => leading to
an inconsistent election result.
[Jorge] the reason why we added this was to leave the door open to use the DP 
capability with other DF Algorithms, but you are right that the above text is 
confusing, especially because the intent was not to specify how to use it for 
the default and HRW algorithms, but to say that the use of DP for any other 
algorithm is out of scope. So we changed the text to:
 The DP capability is supported
 by the Highest-Preference or Lowest-Preference DF Algorithms.
 The procedures of the "Don't Preempt" capability for other DF
 Algorithms are out of the scope of this document.



# NITS

s/tie-breakers/tiebreakers/
s/The existence of both provide/The existence of both provides/
s/achive/achieve/ ?
s/decribed/described/

'e.g.' is usually surrounded by ','
[Jorge] all fixed now





___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)

[Jorge Rabadan (Nokia)]

Hi Warren,

Thank you for reviewing.

We published version 12, which hopefully addresses most of the comments and 
discuss.

About why two algorithms:

Initially only highest-preference was defined and implemented, however, there 
was feedback from the Shepherd and others in the WG that defining the 
Lowest-Preference algorithm would provide more flexibility for the operator. 
For instance, the operator could define the same preference value for two 
Ethernet Segments in a PE1, but, by using highest-preference in ES1 and 
lowest-preference in ES2, we could achieve different DF election results per 
Ethernet Segmen and therefore have some DF distribution.

Other than that, there is no difference between both, they are functionally 
equivalent. Only that one selects the highest value, and the other the lowest 
one.

Since the algorithm itself is signaled in the ES routes, and we explain how 
inconsistencies among PEs are handled, we think there is no additional 
complexity or risks.

If the above explanation is not enough, could you suggest any kind of text or 
guidance that could help clear your DISCUSS?

Thank you!
Jorge


From: Warren Kumari via Datatracker 
Date: Monday, August 7, 2023 at 3:55 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with 
DISCUSS and COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
DISCUSS:
--

Why are there two algorithms (Highest-Preference and Lowest-Preference)?[0]
This seems operationally dangerous and will lead to additional operational
complexity, tricky to debug behaviors, additional implementation complexity,
etc. Assuming that there *is* a good reason (and "Well, we couldn't decide,,
so... ¯\_(ツ)_/¯" isn't one) these should be a section helping operators decide
which algorithm they should deploy, and the pro's and con's of each.

[0]: I did try and find this, but the closest I got was a note in the Shepherd
Writeup saying: "There was a "last minute" agreement on managing the
highest/lowest pref algorithm using different DF algs rather than a single
one+local configs." -- this doesn't actually answer the question.


--
COMMENT:
--

I support John Scudder's DISCUSS, as well as his comments -- the Introduction
seems quite incomplete, and just sort of throws the reader into the deep end.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Zaheduzzaman Sarker's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

[Jorge Rabadan (Nokia)]

Hi Zaheduzzaman,

Thanks for your review.

Section 4.1 bullet D is now completed as follows in version 12:

“A similar procedure can be used for DF Algorithm Lowest-Preference too, that 
is, suppose the algorithm for vES2 is Lowest-Preference, and PE1 (the DF) goes 
on maintenance mode. The operator could change vES2's Preference on PE1 from 
100 to e.g., 250, so that PE2 is forced to take over as Designated Forwarder 
for vES2.”

Hopefully that addresses your comment.

Thanks!
Jorge

From: Zaheduzzaman Sarker via Datatracker 
Date: Monday, August 7, 2023 at 6:14 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: Zaheduzzaman Sarker's No Objection on draft-ietf-bess-evpn-pref-df-11: 
(with COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--

Thanks for working on this specification.

I don't have any transport related points on this specification. However, as
similar != same, it would be great if we can illustrate where the procedure in
section 4.1 bullet D might be different or have different considerations
between Highest-Preference and Lowest-Preference algorithms.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

[Jorge Rabadan (Nokia)]

Hi Murray,

Thank you very much for reviewing.
We just published version 12, which we believe addresses your comments.

Thanks!
Jorge

From: Murray Kucherawy via Datatracker 
Date: Wednesday, August 9, 2023 at 11:40 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 

Subject: Murray Kucherawy's No Objection on draft-ietf-bess-evpn-pref-df-11: 
(with COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--

Section 2 defines "BD" but it's not used anywhere in this document.  Nor are
"NDF", "BDF", "vES", "ISID", or "MAC-VRF".

The sole "SHOULD" in Section 4.1 leaves me with two questions: (1) What happens
if I don't do this?  (2) The sentence itself appears to parse like "You SHOULD
do this, but you don't actually have to" which seems like an abuse of BCP 14.
I think this is better if you just change "SHOULD" to "should", and drop the
BCP 14 references altogether.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

[Jorge Rabadan (Nokia)]

Hi Roman,

Thanks for reviewing.
Your comments, along with John’s and Peter’s should be addressed in version 12 
(recently posted).

Let us know if that is not the case, please.
Thanks!
Jorge

From: Roman Danyliw via Datatracker 
Date: Friday, August 4, 2023 at 12:20 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: Roman Danyliw's No Objection on draft-ietf-bess-evpn-pref-df-11: (with 
COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--

Thank you to Peter Yee for the SECDIR review

I’ll repeat his counsel that the Security Considerations should reference the
applicability of RFC7432.

I support John Scudder’s DISCUSS position.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Lars Eggert's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

[Jorge Rabadan (Nokia)]

Hi Lars,

Thank you very much for your review.
All your comments have been addressed in version 12.
Let us know if you have further questions.

Please see in-line with [Jorge].

Thanks!
Jorge


From: Lars Eggert via Datatracker 
Date: Friday, August 4, 2023 at 4:53 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: Lars Eggert's No Objection on draft-ietf-bess-evpn-pref-df-11: (with 
COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Lars Eggert has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--

# GEN AD review of draft-ietf-bess-evpn-pref-df-11

CC @larseggert

Thanks to Vijay Gurbani for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/yyKue3u0e4F2LuAMSzjlxaEKHrQ).

## Comments

### Section 1.1, paragraph 2
```
 While the Default Designated Forwarder Algorithm [RFC7432] or the
 Highest Random Weight algorithm (HRW) [RFC8584] provide an efficient
 and automated way of selecting the Designated Forwarder across
 different Ethernet Tags in the Ethernet Segment, there are some use-
 cases where a more 'deterministic' and user-controlled method is
 required.  At the same time, Service Providers require an easy way to
```
Why is "deterministic" in quotes here? Is this algorithm not
(always) in fact deterministic? Could a more accurate term be
chosen?
[Jorge] I removed “deterministic”. I think “user-controlled method” conveys the 
meaning that we want in this text.


### Section 4.1, paragraph 1
```
 Assuming the operator wants to control - in a flexible way - what PE
 becomes the Designated Forwarder for a given virtual Ethernet Segment
 and the order in which the PEs become Designated Forwarder in case of
 multiple failures, the following procedure may be used:
```
It's not clear what kind of procedure the list items a-f describe. The
individual list items read more like standalone considerations than
any kind of procedure.
[Jorge] we changed the first paragraph, hopefully it reads better now. Let us 
know please.


## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
[Jorge] ok, thanks.


### Typos

 Section 4.1, paragraph 2
```
-(100,0,Highest-Preferance), (200,0,Highest-Preference) and
- ^
+(100,0,Highest-Preference), (200,0,Highest-Preference) and
+ ^
```

 Section 4.1, paragraph 11
```
-   if PE2's IP addres is lower than PE1's.  Same example applies
+   if PE2's IP address is lower than PE1's.  Same example applies
++
```

 Section 4.2, paragraph 1
```
-Segment.  A potential way to achive a more granular load balancing is
-decribed below.
+Segment.  A potential way to achieve a more granular load balancing is
+ +
+described below.
+  +
```

### Outdated references

Document references `draft-ietf-bess-evpn-virtual-eth-segment-11`, but `-12` is
the latest available revision.
[Jorge] updated, thanks.

### Grammar/style

 Section 4.1, paragraph 3
```
nce is more preferred than PE2's). Hence PE1 becomes the Designated Forwarde
   ^
```
A comma may be missing after the conjunctive/linking adverb "Hence".
[Jorge] added


 Section 4.1, paragraph 4
```
dered list for vES1 is . Hence PE2 becomes the Designated Forwarde
   ^
```
A comma may be missing after the conjunctive/linking adverb "Hence".
[Jorge] added



 Section 4.1, paragraph 6
```
s are used as tie-breakers. If more that one PE is advertising itself as the

```
Did you mean "than"?
[Jorge] fixed


 Section 4.3, paragraph 11
```
with DP=1, that is, PE2 (Pref=200). Hence PE3 will inherit PE2's 

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

[Jorge Rabadan (Nokia)]

Hi Éric,

Thanks very much for the review. Your comments are addressed in version 12.

Please see in line with [Jorge] for more details.

Thanks.
Jorge

From: Éric Vyncke via Datatracker 
Date: Tuesday, August 1, 2023 at 2:35 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: (with 
COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-pref-df-11

Thank you for the work put into this document. Please note that I was close to
ballot a DISCUSS based on my non-blocking COMMENT points, but as I am not an
expert in EPVN, I am trusting the responsible AD.

Please find below osome non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and several nits (please run
your I-D through a spell-checker).
[Jorge] all the nits are fixed now, thanks


Special thanks to Stéphane Litkowski for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status even if
using the old template.

I hope that this review helps to improve the document,
[Jorge] it does, thank you very much.


Regards,

-éric

# COMMENTS

## Abstract

Please fix the expansion of BUM as it is not `Broadcast, Unknown unicast and
Broadcast traffic (BUM)` ;-)
[Jorge] fixed, thanks


## Section 1.1

Please fix the expansion of BUM as it is not `Broadcast, Multicast and Unknown
unicast traffic (BUM)` ;-) I was amused to read two different wrong expansions
for BUM ;-)
[Jorge] yeah, we should have caught it way earlier ☹ - It’s fixed now, thanks


I am sure that non SP will also use this technique, i.e., I wonder whether
s/Service Providers/Network Operators/ would be beneficial.
[Jorge] good point, changed now.


## Section 2

Rather than using "DP" in `DP - refers to the "Don't Preempt me"` should "DNP"
be more logical ?
[Jorge] maybe, but at this point with so many implementations (and debug 
commands showing DP), I prefer to keep it as DP. Hopefully it is ok.


## Section 3

Should RFC 8584 be formally updated as its reserved field is carved out ?

`The DP capability is supported by DF Algorithms Highest-Preference or
Lowest-Preference, and MAY be used with the default DF Algorithm or HRW
[RFC8584]` Is there any migration concern with the use of MAY ? I.e., part of
the participating routers will use the DP and the other part not => leading to
an inconsistent election result.
[Jorge] the reason why we added this was to leave the door open to use the DP 
capability with other DF Algorithms, but you are right that the above text is 
confusing, especially because the intent was not to specify how to use it for 
the default and HRW algorithms, but to say that the use of DP for any other 
algorithm is out of scope. So we changed the text to:
 The DP capability is supported
 by the Highest-Preference or Lowest-Preference DF Algorithms.
 The procedures of the "Don't Preempt" capability for other DF
 Algorithms are out of the scope of this document.



# NITS

s/tie-breakers/tiebreakers/
s/The existence of both provide/The existence of both provides/
s/achive/achieve/ ?
s/decribed/described/

'e.g.' is usually surrounded by ','
[Jorge] all fixed now




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)

[Jorge Rabadan (Nokia)]

Hi John,

Thanks very much for your review. Great comments as usual.
We addressed them in version 12 of the document. Please let us know if this new 
version solves your DISCUSS and COMMENTs.

Also please see in-line with [Jorge].

Thanks!
Jorg

From: John Scudder via Datatracker 
Date: Thursday, August 3, 2023 at 6:14 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: John Scudder's Discuss on draft-ietf-bess-evpn-pref-df-11: (with 
DISCUSS and COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
DISCUSS:
--

# John Scudder, RTG AD, comments for draft-ietf-bess-evpn-pref-df-11
CC @jgscudder

## DISCUSS

Thanks for this specification. It seems needed and useful. Once I put in the
effort I think I understand what you're doing. I think it could be presented
even more clearly, and I offer some suggestions toward that below. I also have
several points I want to raise about possible problem areas, which I hope we'll
be able to work through quickly.

### General, Please Update RFC 8584, add IANA Consideration

Since you modify the definition of the DF Election Extended Community, I think
you should update (with the Updates: metadata) RFC 8584, and in your IANA
Considerations you should add  as an additional reference for DF
Election Extended Community in the EVPN Extended Community Sub-Types registry.
[Jorge] sounds good. Done.

### Section 3, potentially breaks other DF algorithms

You have:

  -  Bit 0 (corresponds to Bit 24 of the Designated Forwarder
 Election Extended Community and it is defined by this
 document): D bit or 'Don't Preempt' bit (DP hereafter),
 determines if the PE advertising the Ethernet Segment route
 requests the remote PEs in the Ethernet Segment not to preempt
 it as Designated Forwarder.  The default value is DP=0, which
 is compatible with the 'preempt' or 'revertive' behavior in the
 Default DF Algorithm [RFC7432].  The DP capability is supported
 by DF Algorithms Highest-Preference or Lowest-Preference, and
 MAY be used with the default DF Algorithm or HRW [RFC8584].
 The procedures of the "Don't Preempt" capability for the
 default DF Algorithm or HRW are out of the scope of this
 document.

A cursory skim of RFC 7432 Section 8.5 leads me to think that the Default DF
Algorithm (at least) works by having all PEs run the election independently;
since they run the same algorithm over the same data they are assumed to come
to the same conclusion, and pick the same DF.

If that understanding is correct then I'm concerned about the last
sentence-and-a-half of the quoted text:

 [the DP capability]
 MAY be used with the default DF Algorithm or HRW [RFC8584].
 The procedures of the "Don't Preempt" capability for the
 default DF Algorithm or HRW are out of the scope of this
 document.

because you've taken the fully-specified algorithm defined in 7432, and made it
underspecified by saying that the DP capability MAY be used with it while
explicitly not saying *how* it is to be used.

Perhaps there's some reason I shouldn't worry about this, or perhaps you should
revise the quoted text. Let's discuss.
[Jorge] I agree, John. Éric also made a similar comment, so the new text says:
>The procedures of the "Don't Preempt" capability for other DF Algorithms are 
>out of the scope of this document. The procedures of the "Don't Preempt" 
>capability for the Highest-Preference and Lowest-Preference DF Algorithms are 
>described in section 4.1.


### Section 4.1, extra "not" inverts meaning of sentence

a given PE in
   the Ethernet Segment is not considered as candidate for Designated
   Forwarder Election until its corresponding Ethernet A-D per ES and
   Ethernet A-D per EVI routes are not received, as described in
   [RFC8584].

Is the second "not" mistaken, in the quoted text, i.e. should "are not
received" actually be "are received"?
[Jorge] good catch. Changed to “are received”

Re: [bess] Secdir last call review of draft-ietf-bess-evpn-pref-df-11

[Jorge Rabadan (Nokia)]

Hi Peter,

Thank you very much for your review.

Please see my comments/resolutions in-line with [Jorge]. All your comments are 
addressed in version 12 that we just published.

Thanks.
Jorge

From: Peter Yee via Datatracker 
Date: Thursday, July 13, 2023 at 3:41 AM
To: sec...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-pref-df@ietf.org 
, last-c...@ietf.org 

Subject: Secdir last call review of draft-ietf-bess-evpn-pref-df-11

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Reviewer: Peter Yee
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The summary of the review is that the document is ready with nits.

The document specifies two new Designated Forwarder algorithms and the
procedures for using them in selecting a Designated Forwarder in an EVPN
network. The only concern that I have is that a malicious actor able to change
the configuration of a PE can unilaterally cause that PE to become the
Designated Forwarder in many situations. This concern is already highlighted
satisfactorily in the Security Considerations.

The two new algorithms share their preference information in the same way the
existing algorithms (in RFC 7432 and RFC 8584) do, so what security protections
there are (such as use of TCP-AO) remain the same. However, this should be
reflected in the security considerations, either by a pointer to a peer
document such as RFC 7432 or inclusion of similar or updated language akin to
that found in a peer document.
[Jorge] makes sense. Added:
“Finally, the two Designated Forwarder Election Algorithms specified in this 
document (Highest-Preference and Lowest-Preference) do not change the way the 
PEs share their Ethernet Segment information, compared to the algorithms in 
[RFC7432]
 and 
[RFC8584].
 Therefore the security considerations in 
[RFC7432]
 and 
[RFC8584]
 apply to this document too.”


Specific items:

Page 1, Abstract, 1st paragraph, 1st sentence: spell out PE on first use with a
parenthetical (PE) after it. That abbreviation is not one of the RFC Editor’s
well-known abbreviations that doesn’t require expansion.
[Jorge] changed, thanks.


Page 1, Abstract, 1st paragraph, 1st sentence: change “Broadcast, Unknown
unicast and Broadcast traffic” to ““Broadcast, Unknown unicast and Multicast
traffic”. Otherwise, you’re going to have to change the abbreviation to BUB.
[Jorge] changed, thanks.


Page 3, section 1.1, 1st paragraph, 1st sentence: change “Broadcast, Multicast
and Unknown   unicast traffic” to “Broadcast, Unknown unicast, and Multicast
traffic”. Or you can change the abbreviation to BMU if you want, but you ought
to be consistent with the Abstract.
[Jorge] changed, thanks.



Page 3, section 1.1, 1st paragraph, 1st sentence: change “in case of” to “in
the case of”.
[Jorge] changed, thanks.



Page 4, section 2: I think you can safely delete the BUM entry having used both
the spelled out and acronym versions prior to this.
[Jorge] changed, thanks.


Page 5, Ethernet Tag definition, last sentence: change “MUST be different from”
to “MUST NOT be”.
[Jorge] changed, thanks.


Page 5, section 3, 3rd sentence: insert “the” before ‘”Don’t Preempt”’. Change
“DF Algorithms Highest-Preference or Lowest-Preference” to “the
Highest-Preference and Lowest-Preference DF Algorithms”.
[Jorge] changed, thanks.


Page 6, Bit 0 definition: make the same change as the previous one above.
[Jorge] changed, thanks.


Page 8, Figure 3: find somewhere to list the expansions of ENNI and CE. I
realize that neither is defined in this document, but the latter could be
ambiguous to some readers.
[Jorge] both added in the terminology section.


Page 9, item ‘a’, 5th sentence: change “Preferance” to “Preference”.
[Jorge] changed, thanks.


Page 9, item ‘b’: assuming that “Section 3” is a reference pack to section 3 of
this document, put it in parentheses or so something else to make it clear that
this is supposed to be a pointer, not the concept that there is some section 3
of the Designated Forward Election Extended Community for holding these
parameters.
[Jorge] changed, thanks.


Page 10, item ‘e’, 2nd 

[bess] I-D Action: draft-ietf-bess-evpn-pref-df-12.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-evpn-pref-df-12.txt is now available. It is a
work item of the BGP Enabled ServiceS (BESS) WG of the IETF.

   Title:   Preference-based EVPN DF Election
   Authors: J. Rabadan
S. Sathappan
W. Lin
J. Drake
A. Sajassi
   Name:draft-ietf-bess-evpn-pref-df-12.txt
   Pages:   20
   Dates:   2023-10-06

Abstract:

   The Designated Forwarder (DF) in Ethernet Virtual Private Networks
   (EVPN) is defined as the Provider Edge (PE) router responsible for
   sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a
   multi-homed device/network in the case of an all-active multi-homing
   Ethernet Segment (ES), or BUM and unicast in the case of single-
   active multi-homing.  The Designated Forwarder is selected out of a
   candidate list of PEs that advertise the same Ethernet Segment
   Identifier (ESI) to the EVPN network, according to the Default
   Designated Forwarder Election algorithm.  While the Default Algorithm
   provides an efficient and automated way of selecting the Designated
   Forwarder across different Ethernet Tags in the Ethernet Segment,
   there are some use cases where a more 'deterministic' and user-
   controlled method is required.  At the same time, Network Operators
   require an easy way to force an on-demand Designated Forwarder
   switchover in order to carry out some maintenance tasks on the
   existing Designated Forwarder or control whether a new active PE can
   preempt the existing Designated Forwarder PE.

   This document proposes a Designated Forwarder Election algorithm that
   meets the requirements of determinism and operation control.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-12

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-pref-df-12

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Diego Achaval (Nokia)]

I support the WG adoption of this draft.

Thanks.
Diego.

From: BESS  on behalf of "Matthew Bocci (Nokia)" 

Date: Thursday, September 28, 2023 at 7:51 AM
To: "bess@ietf.org" 
Cc: "draft-trr-bess-bgp-srv6-a...@ietf.org" 

Subject: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

This email begins a two-week WG adoption and IPR poll for 
draft-trr-bess-bgp-srv6-args-02 [1].

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.
Currently, there is currently no IPR disclosure against this document.

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 Thursday 12th October 2023.

[1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP Services 
(ietf.org)
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Mail regarding draft-ietf-bess-bgp-sdwan-usage

[Zhuangshunwan]

Hi Linda,

Thank you for your reply. I now understand the solution described in the draft 
and I support its WG adoption.

Best Regards,
Shunwan

From: Linda Dunbar [mailto:linda.dun...@futurewei.com]
Sent: Friday, October 6, 2023 4:42 AM
To: Zhuangshunwan ; bess@ietf.org
Subject: RE: Mail regarding draft-ietf-bess-bgp-sdwan-usage

ShunWan,

Thank you very much for review and the detailed comments.

Resolutions to your comments are inserted below.

Linda

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Zhuangshunwan
Sent: Thursday, September 28, 2023 6:40 AM
To: bess@ietf.org
Subject: [bess] Mail regarding draft-ietf-bess-bgp-sdwan-usage


Dear authors,

Some of the text in the section 5.2 of draft-ietf-bess-bgp-sdwan-usage-15 
describes the following:
"
5.2. BGP Walk Through for Homogeneous Encrypted SD-WAN
...

   UPDATE U1:



 - MP-NLRI Path Attribute:

 192.0.2.4/30

 192.0.2.8/30

 - Nexthop: 192.0.2.2 (C-PE2)

 - Encapsulation Extended Community: TYPE = IPsec





   UPDATE U2:

 - MP-NLRI Path Attribute:

 192.0.2.2 (C-PE2)

 - Tunnel Encapsulation Path Attributes (as described in the

 [SECURE-EVPN]) for IPsec SA detailed attributes, including the WAN

 address to be used as the IP address of the IPsec encrypted

 packets.



   If different client routes attached to C-PE2 need to be reached by

   separate IPsec tunnels, the Color-Extended-Community [RFC9012] is

   used to associate routes with the tunnels. See Section 8 of

   [RFC9012].
...
"

I have one comment on the above text:
Regarding the "Encapsulation Extended Community: TYPE = IPsec" in UPDATE U1, 
maybe the possible TYPE should be ESP-Transport or ESP-in-UDP-Transport as 
described in Sections 9.1 and 9.2 of [Security-EVPN]?

[Linda] that is another option. However, since the [Security-EVPN] is further 
away from reaching RFC stage, I feel we should use the standardized type for 
now.

Best Regards,
Shunwan



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Adrian Farrel]

Nice!

 

From: Joel Halpern  
Sent: 06 October 2023 14:24
To: adr...@olddog.co.uk; 'Matthew Bocci (Nokia)' ; 
bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

The rules for joint works are somewhat esoteric, but the short answer is that 
any of the authors have the right to grant rights on behalf of all the authors 
because of the "joint" work nature.  

Yours,

Joel

On 10/6/2023 9:19 AM, Adrian Farrel wrote:

Thanks, Joel.

 

That’s really helpful.

 

Pedantically, suppose there was an author on the old draft who is not an author 
on the new draft?

(I think we are into esoteric grounds here, but just wondering.)

 

A

 

From: Joel Halpern    
Sent: 06 October 2023 14:08
To: adr...@olddog.co.uk  ; 'Matthew Bocci (Nokia)'  
 ; bess@ietf.org 
 
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 
 
Subject: Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

Not speaking for the trust, but as someone who has worked in the rights pace 
for IETF for quite some time, if the authors update the rights grant to grant 
the needed rights (by replacing the boilerplate), then the new draft grants the 
needed rights.  They have legal ability to make such a change.  Sure, it is 
still the case that one can not work directly from the old draft.  The current 
(-17) draft appears to grant the rights, and it is within the authors remit to 
do so.

Yours,

Joel

On 10/6/2023 8:54 AM, Adrian Farrel wrote:

Hi Matthew,

 

I support this being a WG document.

 

IANAL. I don’t understand the process by which an author who previously said 
“no derivative works” for an I-D is able to relax that constraint in a new 
revision. Maybe simply posting a new revision without the constraint is enough. 
Maybe the constraint on the old versions still applies. Would be neat to get an 
opinion from the Trust or IETF Counsel.

 

Cheers,

Adrian

 

From: BESS    On Behalf Of 
Matthew Bocci (Nokia)
Sent: 05 October 2023 11:45
To: bess@ietf.org  
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 
 
Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

WG

 

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

 

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

 

Please review the draft and post any comments to the BESS mailing list.

 

This poll will close on Thursday 12th October.

 

Regards

 

Matthew

 

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network providers. 
 






___
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] Éric Vyncke's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Jeffrey,

Thanks again for your reply. Please look below for EV>

-éric

From: Jeffrey (Zhaohui) Zhang 
Date: Wednesday, 4 October 2023 at 20:24
To: Eric Vyncke (evyncke) , The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)
Hi Eric,

Thanks for your additional comments.
Please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Éric Vyncke via Datatracker 
Sent: Wednesday, October 4, 2023 4:54 AM
To: The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; slitkows.i...@gmail.com; slitkows.i...@gmail.com
Subject: Éric Vyncke's No Objection on 
draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)

[External Email. Be cautious of content]


Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-13: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!FEgMbJglM32kNpUq8oHsJACNotxG8OsVTbawC8CSmY6LxXGvbXL5dg2IGipM1_A9Gt7HJwasAU7uYvU$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!FEgMbJglM32kNpUq8oHsJACNotxG8OsVTbawC8CSmY6LxXGvbXL5dg2IGipM1_A9Gt7HJwasNmJJFr4$



--
COMMENT:
--

Thanks to Zhaohui Zhang and Stéphane Litkowski for addressing my previous 
DISCUSS points (even if they were 'discuss discuss', i.e., just to have a 
discussion). I have now cleared my previous DISCUSS ballot.

# COMMENTS

## Abstract

Should the abstract qualify the VPN with layer-3 (for MVPN) and layer-2 (for
EVPN) ?

Zzh> In this document, VPN refers to IP VPN. L2 VPN is specifically EVPN.
Zzh> I can change VPN to IP VPN in the abstract, and then in the first section 
clarify that VPN specifically refers to IP VPN.
Zzh> Is that ok?

EV> perfect

## Section 1

Should "SR" also be expanded ? Should RFC 8660 be a reference ?

Zzh> Changed and added.

## Section 2

`to transmit multicast traffic or BUM traffic` is somehow redundant as BUM 
includes multicast.

Zzh> Changed to "to transmit VPN multicast  traffic or EVPN BUM traffic".

## Section 2.1

`At the present time` what about "In 2023, " ?

Zzh> Changed to "So far, ".

EV> still “so far” does not age well ;-)


## Section 3.1

Please expand "EC" at first use (even if it can be guessed on the previous 
sentence).

Zzh> Fixed.

Why this section use `to be defined by IANA`, while section 5 lists the 
IANA-assigned values ?

Zzh> Fixed.

## Section 3.2

This I-D uses 'outside the scope of this document' twice. I am curious: is 
there any work in BESS WG for this ?

Zzh> No at this time 
Zzh> Coordinated label assignment is like IP address assignment.
Zzh> Ensuring all PEs supporting the procedures is like an operator making sure 
that all its PEs are running a certain software release.

# NITS

zzh> All fixed. To be posted.
Zzh> Thanks!
Zzh> Jeffrey

## Section 1

s/Terminologies/Terminology/

s/Broadcast, Unknown *U*nicast, or Multicast (traffic)/Broadcast, Unknown 
*u*nicast, or Multicast (packet)/

s/sub set/subset/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Joel Halpern]

The rules for joint works are somewhat esoteric, but the short answer is 
that any of the authors have the right to grant rights on behalf of all 
the authors because of the "joint" work nature.


Yours,

Joel

On 10/6/2023 9:19 AM, Adrian Farrel wrote:


Thanks, Joel.

That’s really helpful.

Pedantically, suppose there was an author on the old draft who is not 
an author on the new draft?


(I think we are into esoteric grounds here, but just wondering.)

A

*From:*Joel Halpern 
*Sent:* 06 October 2023 14:08
*To:* adr...@olddog.co.uk; 'Matthew Bocci (Nokia)' 
; bess@ietf.org

*Cc:* draft-ietf-bess-bgp-sdwan-us...@ietf.org
*Subject:* Re: [bess] WG Adoption Poll for 
draft-ietf-bess-bgp-sdwan-uasge-16


Not speaking for the trust, but as someone who has worked in the 
rights pace for IETF for quite some time, if the authors update the 
rights grant to grant the needed rights (by replacing the 
boilerplate), then the new draft grants the needed rights.  They have 
legal ability to make such a change.  Sure, it is still the case that 
one can not work directly from the old draft.  The current (-17) draft 
appears to grant the rights, and it is within the authors remit to do so.


Yours,

Joel

On 10/6/2023 8:54 AM, Adrian Farrel wrote:

Hi Matthew,

I support this being a WG document.

IANAL. I don’t understand the process by which an author who
previously said “no derivative works” for an I-D is able to relax
that constraint in a new revision. Maybe simply posting a new
revision without the constraint is enough. Maybe the constraint on
the old versions still applies. Would be neat to get an opinion
from the Trust or IETF Counsel.

Cheers,

Adrian

*From:*BESS  
*On Behalf Of *Matthew Bocci (Nokia)
*Sent:* 05 October 2023 11:45
*To:* bess@ietf.org
*Cc:* draft-ietf-bess-bgp-sdwan-us...@ietf.org
*Subject:* [bess] WG Adoption Poll for
draft-ietf-bess-bgp-sdwan-uasge-16

WG

This email starts a one-week WG adoption poll for
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

A little bit of history: A previous version was adopted, completed
WG last call, and publication requested as an Informational RFC.
v15 of this draft was reviewed by the IESG and found to have a
restrictive clause in the boilerplate. This has now been removed,
but since that clause was inconsistent with the draft having been
adopted as a WG document in the first place, we have been asked to
go through the process again.

Please review the draft and post any comments to the BESS mailing
list.

This poll will close on Thursday 12^th October.

Regards

Matthew

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are
commonly interconnected by multiple types of underlay networks
owned and managed by different network providers.




___

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] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Adrian Farrel]

Thanks, Joel.

 

That’s really helpful.

 

Pedantically, suppose there was an author on the old draft who is not an author 
on the new draft?

(I think we are into esoteric grounds here, but just wondering.)

 

A

 

From: Joel Halpern  
Sent: 06 October 2023 14:08
To: adr...@olddog.co.uk; 'Matthew Bocci (Nokia)' ; 
bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

Not speaking for the trust, but as someone who has worked in the rights pace 
for IETF for quite some time, if the authors update the rights grant to grant 
the needed rights (by replacing the boilerplate), then the new draft grants the 
needed rights.  They have legal ability to make such a change.  Sure, it is 
still the case that one can not work directly from the old draft.  The current 
(-17) draft appears to grant the rights, and it is within the authors remit to 
do so.

Yours,

Joel

On 10/6/2023 8:54 AM, Adrian Farrel wrote:

Hi Matthew,

 

I support this being a WG document.

 

IANAL. I don’t understand the process by which an author who previously said 
“no derivative works” for an I-D is able to relax that constraint in a new 
revision. Maybe simply posting a new revision without the constraint is enough. 
Maybe the constraint on the old versions still applies. Would be neat to get an 
opinion from the Trust or IETF Counsel.

 

Cheers,

Adrian

 

From: BESS    On Behalf Of 
Matthew Bocci (Nokia)
Sent: 05 October 2023 11:45
To: bess@ietf.org  
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 
 
Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

WG

 

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

 

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

 

Please review the draft and post any comments to the BESS mailing list.

 

This poll will close on Thursday 12th October.

 

Regards

 

Matthew

 

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network providers. 
 





___
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] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Zhuangshunwan]

I support WG adoption.

Best regards,
Shunwan


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Matthew Bocci (Nokia)
Sent: Thursday, October 5, 2023 6:45 PM
To: bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

WG

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

Please review the draft and post any comments to the BESS mailing list.

This poll will close on Thursday 12th October.

Regards

Matthew

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network 
providers.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Joel Halpern]

Not speaking for the trust, but as someone who has worked in the rights 
pace for IETF for quite some time, if the authors update the rights 
grant to grant the needed rights (by replacing the boilerplate), then 
the new draft grants the needed rights.  They have legal ability to make 
such a change.  Sure, it is still the case that one can not work 
directly from the old draft.  The current (-17) draft appears to grant 
the rights, and it is within the authors remit to do so.


Yours,

Joel

On 10/6/2023 8:54 AM, Adrian Farrel wrote:


Hi Matthew,

I support this being a WG document.

IANAL. I don’t understand the process by which an author who 
previously said “no derivative works” for an I-D is able to relax that 
constraint in a new revision. Maybe simply posting a new revision 
without the constraint is enough. Maybe the constraint on the old 
versions still applies. Would be neat to get an opinion from the Trust 
or IETF Counsel.


Cheers,

Adrian

*From:*BESS  *On Behalf Of *Matthew Bocci (Nokia)
*Sent:* 05 October 2023 11:45
*To:* bess@ietf.org
*Cc:* draft-ietf-bess-bgp-sdwan-us...@ietf.org
*Subject:* [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

WG

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]


A little bit of history: A previous version was adopted, completed WG 
last call, and publication requested as an Informational RFC. v15 of 
this draft was reviewed by the IESG and found to have a restrictive 
clause in the boilerplate. This has now been removed, but since that 
clause was inconsistent with the draft having been adopted as a WG 
document in the first place, we have been asked to go through the 
process again.


Please review the draft and post any comments to the BESS mailing list.

This poll will close on Thursday 12^th October.

Regards

Matthew

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are 
commonly interconnected by multiple types of underlay networks owned 
and managed by different network providers. 




___
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] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Adrian Farrel]

Hi Matthew,

 

I support this being a WG document.

 

IANAL. I don't understand the process by which an author who previously said
"no derivative works" for an I-D is able to relax that constraint in a new
revision. Maybe simply posting a new revision without the constraint is
enough. Maybe the constraint on the old versions still applies. Would be
neat to get an opinion from the Trust or IETF Counsel.

 

Cheers,

Adrian

 

From: BESS  On Behalf Of Matthew Bocci (Nokia)
Sent: 05 October 2023 11:45
To: bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

WG

 

This email starts a one-week WG adoption poll for
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

 

A little bit of history: A previous version was adopted, completed WG last
call, and publication requested as an Informational RFC. v15 of this draft
was reviewed by the IESG and found to have a restrictive clause in the
boilerplate. This has now been removed, but since that clause was
inconsistent with the draft having been adopted as a WG document in the
first place, we have been asked to go through the process again.

 

Please review the draft and post any comments to the BESS mailing list.

 

This poll will close on Thursday 12th October.

 

Regards

 

Matthew

 

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly
interconnected by multiple types of underlay networks owned and managed by
different network providers.
 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR, implementation poll for draft-ietf-bess-evpn-irb-extended-mobility

[slitkows.ietf]

Hi,

 

New WGLC is now closed and no objection has been raised.

Authors confirmed again unawareness of any undisclosed IPR.

 

We got again confirmation that implementation exists.

 

We'll move forward with the draft.

I'll review it again and provide any comments.

 

 

Stephane

 

 

From: Ali Sajassi (sajassi)  
Sent: Tuesday, September 19, 2023 11:51 PM
To: slitkows.i...@gmail.com; bess@ietf.org;
draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR, implementation poll for
draft-ietf-bess-evpn-irb-extended-mobility

 

I am not aware of any undisclosed IPRs.

 

Cheers,

Ali

 

From: BESS mailto:bess-boun...@ietf.org> > on behalf
of slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com> >
Date: Tuesday, September 19, 2023 at 12:45 AM
To: bess@ietf.org   mailto:bess@ietf.org> >,
draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org

mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org> >
Cc: bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org> >
Subject: [bess] WGLC, IPR, implementation poll for
draft-ietf-bess-evpn-irb-extended-mobility

Hi WG,

 

This email starts a two-week Working Group Last Call on
draft-ietf-bess-evpn-irb-extended-mobility-14 [1]. Note that the document
already had a WGLC and comments were raised by the WG. These comments are
normally addressed by the Authors but feel free to review again and provide
feedback.

 

This poll runs until Tuesday 3rd October.

 

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. The Document won't progress without answers from
all the Authors and Contributors. 

There is currently no IPR disclosed.

 

If you are not listed as an Author or a Contributor, then please explicitly
respond only if you are aware of any IPR that has not yet been disclosed in
conformance with IETF rules.

 

We are also polling for any existing implementation as per [2]. Please
indicate if you are aware of any implementations.

 

 

 

Thank you,

Stephane, Matthew, Jeffrey

 

[1]

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/

[2]

https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Fw: Need your help to support the WG Adoption (FW: WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[liupeng...@outlook.com]

Hi, WG, 

Yes, I support the adoption of this document.

Regards,
Peng Liu(CMCC)
 
From: Matthew Bocci (Nokia)  
Sent: Thursday, October 5, 2023 5:45 AM
To: bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16
 
WG
 
This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]
 
A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.
 
Please review the draft and post any comments to the BESS mailing list.
 
This poll will close on Thursday 12th October.
 
Regards
 
Matthew
 
[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network providers.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess