[bess] John Scudder's No Objection on draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-bess-pbb-evpn-isid-cmacflush-08: 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-pbb-evpn-isid-cmacflush/



--
COMMENT:
--

- General: I'm taking it on faith that the flush procedures are properly
specified in one of the underlying specs. This one doesn't, it just is an
overlay that says "do the flush procedure but with this different trigger".

- General: G.8032 should be at least an Informative reference.

- Section 1.1: Terms defined but never used, or used only once (so could be
inline)
  - B-Component (used only once)
  - vES (never used)
  - I-Component (only used once)
  - RD and RT are used only once, too

- Section 2(d), It's not obvious to me what "double flushing" means (and I do
know something about route reflectors).

- Section 3, "The MAC Mobility extended community is used as in [RFC7623],
where a delta in the sequence number between two updates for the same
B-MAC/I-SID will be interpreted as a C-MAC-flush notification for the
corresponding B-MAC and I-SID", it seems to me that "a delta in the sequence
number" is a more casual description than is warranted? Looking at RFC 7423, it
appears the sequence number has to be incremented (modulo sequence wrap), not
just different (which is what "delta" implies). I guess a simple fix would be
s/a delta/an increment/. (Occurs again in Section 4.2, and again in Section
4.3. Just grep for "delta".)

- Section 4, where you write "Enabling or disabling I-SID-based C-MAC-flush
SHOULD be an administrative choice on the system that MAY be configured per
I-SID (I-Component). When enabled on a PE:", do you really mean the MAY to be
interpreted in the sense of RFC 2119, i.e. it's completely optional? Or do you
mean "may"?

- Section 5(e), "The solution can coexist in a network with systems supporting
or not supporting this specification." I guess the coexistence with
non-supporting systems is that they just ignore the new style of route, and
have to age out the MACs the old-fashioned way (with concomitant loss of
traffic)?



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

Re: [bess] Appointment of additional WG Chair

[Linda Dunbar]

Congratulations Jeffrey!

Best Regards
Linda

发件人: BESS mailto:bess-boun...@ietf.org>> 代表 Andrew 
Alston - IETF
发送时间: 2023年8月4日 10:45
收件人: bess@ietf.org
抄送: bess-cha...@ietf.org
主题: [bess] Appointment of additional WG Chair

Hi WG,

Following consultation with Matt and Stephane I have opted to appoint a third 
chair to BESS to provide additional coverage considering the document working 
load through the working group.

As such, I would like to welcome Jeffery Zhang as the third chair to BESS and 
to thank him for his willingness to take up the position.  I believe Jeffrey 
will be a solid addition to the team.

Thanks

Andrew Alston
Routing Area Director



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

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

[Roman Danyliw via Datatracker]

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] Appointment of additional WG Chair

[Susan Hares]

Congratulations Jeffrey!

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

Re: [bess] [Gen-art] Genart last call review of draft-ietf-bess-evpn-pref-df-10

[Lars Eggert]

Vijay, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On Jul 2, 2023, at 22:13, Vijay Gurbani via Datatracker  
> wrote:
> 
> Reviewer: Vijay Gurbani
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-bess-evpn-pref-df-10
> Reviewer: Vijay K. Gurbani
> Review Date: 2023-07-02
> IETF LC End Date: 2023-07-11
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The draft is ready for publications as a Proposed Standard with a few
> nite.
> 
> Major issues: 0
> 
> Minor issues: 1 (please see below)
> 
> Nits/editorial comments: 3 (please see below)
> 
> Minor
> 
> - Sec 2, you may consider ordering the abbreviations alphabetically as it may
> be easier for the reader to find what they are looking for.
> 
> Nits:
> 
> - Sec 1.1, s/two new DF Algs/two new DF algorithms/ (unless, of course, in 
> your
> nomenclature, "Alg" means something specific).
> 
> - Sec 3, the opening sentence is too long.  You may consider the following
> edit: s/route, by replacing/route.  It does so by replacing/
> 
> - Sec 4.1, bullet d, s/E.g., 50/e.g., 50/
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Lars Eggert via Datatracker]

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?

### 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.

## 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.

### 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.

### 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".

 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".

 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"?

 Section 4.3, paragraph 11
```
with DP=1, that is, PE2 (Pref=200). Hence PE3 will inherit PE2's preference a
^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

 Section 4.3, paragraph 19
```
warder Election Algorithm different than the one configured in the rest of t

```
Did you mean "different from"? "Different than" is often considered colloquial
style.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



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

Re: [bess] Appointment of additional WG Chair

[zhang.zheng]

Congratulations Jeffrey!






Best regards,


Sandy







Original



From: AndrewAlston-IETF 
To: bess@ietf.org ;
Cc: bess-cha...@ietf.org ;
Date: 2023年08月04日 10:45
Subject: [bess] Appointment of additional WG Chair


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

 

Hi WG,


 


Following consultation with Matt and Stephane I have opted to appoint a third 
chair to BESS to provide additional coverage considering the document working 
load through the working group.


 


As such, I would like to welcome Jeffery Zhang as the third chair to BESS and 
to thank him for his willingness to take up the position.  I believe Jeffrey 
will be a solid addition to the team.


 


Thanks


 


Andrew Alston


Routing Area Director


 



 
Internal All Employees___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Appointment of additional WG Chair

[wei.yuehua]

Congratulations Jeffrey!
Best Regards,
Yuehua Wei
ZTE Corporation
--Original--
From: AndrewAlston-IETF 
To: bess@ietf.org ;
Cc: bess-cha...@ietf.org ;
Date: 2023年08月04日 10:45
Subject: [bess] Appointment of additional WG Chair
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Hi WG,
Following consultation with Matt and Stephane I have opted to appoint a third 
chair to BESS to provide additional coverage considering the document working 
load through the working group.
As such, I would like to welcome Jeffery Zhang as the third chair to BESS and 
to thank him for his willingness to take up the position.  I believe Jeffrey 
will be a solid addition to the team.
Thanks
Andrew Alston
Routing Area Director

Internal All Employees

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

Re: [bess] Appointment of additional WG Chair

[liuyisong]

Congratulations Jeffrey!

 

Best Regards

Yisong

 

发件人: BESS  代表 Andrew Alston - IETF
发送时间: 2023年8月4日 10:45
收件人: bess@ietf.org
抄送: bess-cha...@ietf.org
主题: [bess] Appointment of additional WG Chair

 

Hi WG,

 

Following consultation with Matt and Stephane I have opted to appoint a
third chair to BESS to provide additional coverage considering the document
working load through the working group.

 

As such, I would like to welcome Jeffery Zhang as the third chair to BESS
and to thank him for his willingness to take up the position.  I believe
Jeffrey will be a solid addition to the team.

 

Thanks

 

Andrew Alston

Routing Area Director

 

 

Internal All Employees

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

Re: [bess] Appointment of additional WG Chair

[chen.ran]

Congratulations Jeffery！ 


Best Regards,


Ran


-


On Thu, Aug 3, 2023 at 10:45 PM Andrew Alston - IETF 
 wrote:


Hi WG,


 


Following consultation with Matt and Stephane I have opted to appoint a third 
chair to BESS to provide additional coverage considering the document working 
load through the working group.


 


As such, I would like to welcome Jeffery Zhang as the third chair to BESS and 
to thank him for his willingness to take up the position.  I believe Jeffrey 
will be a solid addition to the team.


 


Thanks


 


Andrew Alston


Routing Area Director___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess