Re: [bess] John Scudder's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi John,

Thanks for your review and for catching those issues.
I posted -13 revision that addresses them (and some comments from others).
https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-aggregation-label-12&url2=draft-ietf-bess-mvpn-evpn-aggregation-label-13&difftype=--html

Please see zzh> below for two clarifications.


Juniper Business Use Only
-Original Message-
From: John Scudder via Datatracker 
Sent: Tuesday, October 3, 2023 6:06 PM
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; 
idr-cha...@ietf.org
Subject: John Scudder's Discuss on 
draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


John Scudder has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-12: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9ysPLbofw$
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!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9y8nKQlYI$



--
DISCUSS:
--

# John Scudder, RTG AD, comments for
draft-ietf-bess-mvpn-evpn-aggregation-label-12 CC @jgscudder

Thanks for this spec. I have one serious concern (but I think it will be easy 
to take care of) and a few comments and nits.

(Sorry for the iteration on this ballot, I missed one of my pages of notes in 
my haste to get this sent off.)

## DISCUSS

### Section 3.2, ignoring routes considered harmful

Zzh> You're right. Thanks for the detailed explanation. I changed both to 
"treat-as-withdraw".

There are two places toward the end of this subsection where you specify that a 
route must be ignored. The first is:

"A PE MUST ignore a received route with both the DCB-flag and the Context Label 
Space ID EC attached, treating as if it was not received."

The second is:

"If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure 
one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."

Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be 
exceptions, if the conditions for ignoring the routes are carefully chosen so 
that correctness (or something like it) is preserved, but as a general matter, 
ignoring routes is a one-way ticket to persistent traffic loss or worse. It's 
for this reason that RFC 7606 specifies treat-as-withdraw for many error 
conditions. I'll illustrate the general problem with an example that uses 
simple IPv4 unicast routes:

- Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and install 
it in the FIB. - Now suppose the router that advertised it to us sends a 
replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path 
attribute P that we decide is malformed. We ignore the route as our error 
handling strategy. - We are left in a state where we still have 10/8 via
1.1.1.1 selected and installed, because we ignored the replacement, "treating 
it as if was not received". This is an incorrect state. I can easily show you 
scenarios where it leads to traffic loss, persistent loops, etc. - The correct 
behavior in this scenario would be to remove the 10/8 route received in the 
first step; RFC 7606 calls this "treat-as-withdraw".

It might be that something special about MVPN/EVPN routes means this isn't an 
issue for the two cases I've quoted, but you haven't made this clear in the 
document. I think at minimum, some analysis is needed to show that the strategy 
is OK. On the other hand if what you meant by "ignore" is something closer to 
the "treat-as-withdraw" strategy, I think the language has to be made more 
specific and leave less to the creativity and imagination of the implementor.

Let's have a discussion about which it is, and see where to go from there.

Edited to add: I sent this as a followup to my original ballot, with cc
idr-chairs: "I suspect my DISCUSS would have been caught if there had been 
review from IDR. Searching for the draft name in the IDR mailing list archive 
doesn’t surface any traffic about it, so I’m guessing this didn’t occur."


--
COMMENT:
-

[bess] I-D Action: draft-ietf-bess-mvpn-evpn-aggregation-label-13.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-mvpn-evpn-aggregation-label-13.txt is now
available. It is a work item of the BGP Enabled ServiceS (BESS) WG of the
IETF.

   Title:   MVPN/EVPN Tunnel Aggregation with Common Labels
   Authors: Zhaohui Zhang
Eric Rosen
Wen Lin
Zhenbin Li
IJsbrand Wijnands
   Name:draft-ietf-bess-mvpn-evpn-aggregation-label-13.txt
   Pages:   17
   Dates:   2023-10-03

Abstract:

   The MVPN specifications allow a single Point-to-Multipoint (P2MP)
   tunnel to carry traffic of multiple VPNs.  The EVPN specifications
   allow a single P2MP tunnel to carry traffic of multiple Broadcast
   Domains (BDs).  These features require the ingress router of the P2MP
   tunnel to allocate an upstream-assigned MPLS label for each VPN or
   for each BD.  A packet sent on a P2MP tunnel then carries the label
   that is mapped to its VPN or BD (in some cases, a distinct upstream-
   assigned label is needed for each flow.)  Since each ingress router
   allocates labels independently, with no coordination among the
   ingress routers, the egress routers may need to keep track of a large
   number of labels.  The number of labels may need to be as large (or
   larger) than the product of the number of ingress routers times the
   number of VPNs or BDs.  However, the number of labels can be greatly
   reduced if the association between a label and a VPN or BD is made by
   provisioning, so that all ingress routers assign the same label to a
   particular VPN or BD.  New procedures are needed in order to take
   advantage of such provisioned labels.  These new procedures also
   apply to Multipoint-to-Multipoint (MP2MP) tunnels.  This document
   updates RFCs 6514, 7432 and 7582 by specifying the necessary
   procedures.

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-aggregation-label-13

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-mvpn-evpn-aggregation-label-13

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

[bess] John Scudder's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-12: 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-mvpn-evpn-aggregation-label/



--
DISCUSS:
--

# John Scudder, RTG AD, comments for
draft-ietf-bess-mvpn-evpn-aggregation-label-12 CC @jgscudder

Thanks for this spec. I have one serious concern (but I think it will be easy
to take care of) and a few comments and nits.

(Sorry for the iteration on this ballot, I missed one of my pages of notes in
my haste to get this sent off.)

## DISCUSS

### Section 3.2, ignoring routes considered harmful

There are two places toward the end of this subsection where you specify that a
route must be ignored. The first is:

"A PE MUST ignore a received route with both the DCB-flag and the Context Label
Space ID EC attached, treating as if it was not received."

The second is:

"If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure
one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."

Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be
exceptions, if the conditions for ignoring the routes are carefully chosen so
that correctness (or something like it) is preserved, but as a general matter,
ignoring routes is a one-way ticket to persistent traffic loss or worse. It's
for this reason that RFC 7606 specifies treat-as-withdraw for many error
conditions. I'll illustrate the general problem with an example that uses
simple IPv4 unicast routes:

- Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and install
it in the FIB. - Now suppose the router that advertised it to us sends a
replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path
attribute P that we decide is malformed. We ignore the route as our error
handling strategy. - We are left in a state where we still have 10/8 via
1.1.1.1 selected and installed, because we ignored the replacement, "treating
it as if was not received". This is an incorrect state. I can easily show you
scenarios where it leads to traffic loss, persistent loops, etc. - The correct
behavior in this scenario would be to remove the 10/8 route received in the
first step; RFC 7606 calls this "treat-as-withdraw".

It might be that something special about MVPN/EVPN routes means this isn't an
issue for the two cases I've quoted, but you haven't made this clear in the
document. I think at minimum, some analysis is needed to show that the strategy
is OK. On the other hand if what you meant by "ignore" is something closer to
the "treat-as-withdraw" strategy, I think the language has to be made more
specific and leave less to the creativity and imagination of the implementor.

Let's have a discussion about which it is, and see where to go from there.

Edited to add: I sent this as a followup to my original ballot, with cc
idr-chairs: "I suspect my DISCUSS would have been caught if there had been
review from IDR. Searching for the draft name in the IDR mailing list archive
doesn’t surface any traffic about it, so I’m guessing this didn’t occur."


--
COMMENT:
--

## COMMENTS

### Section 3, EC

Please expand "EC" on first use, or put it in your glossary, or my personal
favorite, just use the words "Extended Community" and remove "EC" altogether,
it's unnecessary and (in my opinion) unhelpful to abbreviate it.

### Section 3.1, need registry?

You have an ID-Type and define the semantics of type 0. You probably should
create a registry for the unallocated types.

### Section 3.1, AND or OR?

You have:

   In the remainder of the document, when we say a BGP-MVPN/EVPN A-D
   route "carries DCB-flag" or "has DCB-flag attached" we mean the
   following:

   *  The route carries a PMSI Tunnel Attribute (PTA) and its Flags
  field has the Extension bit set

   *  The route carries an "Additional PMSI Tunnel Attribute Flags" EC
  and its DCB flag is set

I think you need to indicate if the bullets are ANDed or ORed. I infer from
later context that they're ORed, in which case perhaps "we mean one or the
other of the following".

### Section 3.1, values aren't TBA, they've been assigned

You write, "Sub-Type value to be assigned by IANA". But your IANA section shows
that the sub-type has been assigned the value 0x08. Pleas

Re: [bess] John Scudder's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[John Scudder]

+idr-chairs

One further point — I suspect my DISCUSS would have been caught if there had 
been review from IDR. Searching for the draft name in the IDR mailing list 
archive doesn’t surface any traffic about it, so I’m guessing this didn’t 
occur. 

—John

> On Oct 3, 2023, at 5:56 PM, John Scudder via Datatracker  
> wrote:
> 
> John Scudder has entered the following ballot position for
> draft-ietf-bess-mvpn-evpn-aggregation-label-12: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!AaZxbUvcTcuLpq8L04uUQFDmK0Znk9LVAqEHL-EoPjN8MVaLLL4nTnINEew0S-wWnWmfeUaGqLue$
> 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!AaZxbUvcTcuLpq8L04uUQFDmK0Znk9LVAqEHL-EoPjN8MVaLLL4nTnINEew0S-wWnWmfeTD7xO5C$
> 
> 
> 
> --
> DISCUSS:
> --
> 
> # John Scudder, RTG AD, comments for
> draft-ietf-bess-mvpn-evpn-aggregation-label-12 CC @jgscudder
> 
> Thanks for this spec. I have one serious concern (but I think it will be easy
> to take care of) and a few comments and nits.
> 
> ## DISCUSS
> 
> ### Section 3.2, ignoring routes considered harmful
> 
> There are two places toward the end of this subsection where you specify that 
> a
> route must be ignored. The first is:
> 
> "A PE MUST ignore a received route with both the DCB-flag and the Context 
> Label
> Space ID EC attached, treating as if it was not received."
> 
> The second is:
> 
> "If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST 
> ensure
> one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."
> 
> Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be
> exceptions, if the conditions for ignoring the routes are carefully chosen so
> that correctness (or something like it) is preserved, but as a general matter,
> ignoring routes is a one-way ticket to persistent traffic loss or worse. It's
> for this reason that RFC 7606 specifies treat-as-withdraw for many error
> conditions. I'll illustrate the general problem with an example that uses
> simple IPv4 unicast routes:
> 
> - Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and 
> install
> it in the FIB. - Now suppose the router that advertised it to us sends a
> replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path
> attribute P that we decide is malformed. We ignore the route as our error
> handling strategy. - We are left in a state where we still have 10/8 via
> 1.1.1.1 selected and installed, because we ignored the replacement, "treating
> it as if was not received". This is an incorrect state. I can easily show you
> scenarios where it leads to traffic loss, persistent loops, etc. - The correct
> behavior in this scenario would be to remove the 10/8 route received in the
> first step; RFC 7606 calls this "treat-as-withdraw".
> 
> It might be that something special about MVPN/EVPN routes means this isn't an
> issue for the two cases I've quoted, but you haven't made this clear in the
> document. I think at minimum, some analysis is needed to show that the 
> strategy
> is OK. On the other hand if what you meant by "ignore" is something closer to
> the "treat-as-withdraw" strategy, I think the language has to be made more
> specific and leave less to the creativity and imagination of the implementor.
> 
> Let's have a discussion about which it is, and see where to go from there.
> 
> 
> --
> COMMENT:
> --
> 
> ## COMMENTS
> 
> ### Section 3, EC
> 
> Please expand "EC" on first use, or put it in your glossary, or my personal
> favorite, just use the words "Extended Community" and remove "EC" altogether,
> it's unnecessary and (in my opinion) unhelpful to abbreviate it.
> 
> ### Section 3.1, need registry?
> 
> You have an ID-Type and define the semantics of type 0. You probably should
> create a registry for the unallocated types.
> 
> ### Section 3.1, AND or OR?
> 
> You have:
> 
>   In the remainder of the document, when we say a BGP-MVPN/EVPN A-D
>   route "carries DCB-flag" or "has DCB-flag attached" we mean the
>   following:
> 
>   *  The route carries a PMSI Tunnel Attribute (PTA) and its Flags
>  field has the Extension bit set
> 
>   *  The route carries an "Additional PMSI Tunnel Attribute Flags" EC
>  and its DCB flag is set

[bess] John Scudder's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-12: 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-mvpn-evpn-aggregation-label/



--
DISCUSS:
--

# John Scudder, RTG AD, comments for
draft-ietf-bess-mvpn-evpn-aggregation-label-12 CC @jgscudder

Thanks for this spec. I have one serious concern (but I think it will be easy
to take care of) and a few comments and nits.

## DISCUSS

### Section 3.2, ignoring routes considered harmful

There are two places toward the end of this subsection where you specify that a
route must be ignored. The first is:

"A PE MUST ignore a received route with both the DCB-flag and the Context Label
Space ID EC attached, treating as if it was not received."

The second is:

"If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure
one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."

Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be
exceptions, if the conditions for ignoring the routes are carefully chosen so
that correctness (or something like it) is preserved, but as a general matter,
ignoring routes is a one-way ticket to persistent traffic loss or worse. It's
for this reason that RFC 7606 specifies treat-as-withdraw for many error
conditions. I'll illustrate the general problem with an example that uses
simple IPv4 unicast routes:

- Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and install
it in the FIB. - Now suppose the router that advertised it to us sends a
replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path
attribute P that we decide is malformed. We ignore the route as our error
handling strategy. - We are left in a state where we still have 10/8 via
1.1.1.1 selected and installed, because we ignored the replacement, "treating
it as if was not received". This is an incorrect state. I can easily show you
scenarios where it leads to traffic loss, persistent loops, etc. - The correct
behavior in this scenario would be to remove the 10/8 route received in the
first step; RFC 7606 calls this "treat-as-withdraw".

It might be that something special about MVPN/EVPN routes means this isn't an
issue for the two cases I've quoted, but you haven't made this clear in the
document. I think at minimum, some analysis is needed to show that the strategy
is OK. On the other hand if what you meant by "ignore" is something closer to
the "treat-as-withdraw" strategy, I think the language has to be made more
specific and leave less to the creativity and imagination of the implementor.

Let's have a discussion about which it is, and see where to go from there.


--
COMMENT:
--

## COMMENTS

### Section 3, EC

Please expand "EC" on first use, or put it in your glossary, or my personal
favorite, just use the words "Extended Community" and remove "EC" altogether,
it's unnecessary and (in my opinion) unhelpful to abbreviate it.

### Section 3.1, need registry?

You have an ID-Type and define the semantics of type 0. You probably should
create a registry for the unallocated types.

### Section 3.1, AND or OR?

You have:

   In the remainder of the document, when we say a BGP-MVPN/EVPN A-D
   route "carries DCB-flag" or "has DCB-flag attached" we mean the
   following:

   *  The route carries a PMSI Tunnel Attribute (PTA) and its Flags
  field has the Extension bit set

   *  The route carries an "Additional PMSI Tunnel Attribute Flags" EC
  and its DCB flag is set

I think you need to indicate if the bullets are ANDed or ORed. I infer from
later context that they're ORed, in which case perhaps "we mean one or the
other of the following".

## NITS

### Section 2.2

- "number of total number of labels" --> too many "number of"s

### Section 2.2.2.3

- "w/o" --> "without"

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

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



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

Re: [bess] A question regarding sections 15.2 and 15.3 of draft-ietf-bess-rfc7432bis

[Ali Sajassi (sajassi)]

Hi Sasha,

As always thanks for your insightful comments and questions and sorry for the 
delayed response. Please refer to my responses inline marked with [AS].

From: BESS  on behalf of Alexander Vainshtein 

Date: Tuesday, September 26, 2023 at 2:56 AM
To: draft-ietf-bess-rfc7432bis.auth...@ietf.org 

Cc: bess@ietf.org 
Subject: [bess] A question regarding sections 15.2 and 15.3 of 
draft-ietf-bess-rfc7432bis
Hi all,
I have a question regarding sections 15.2 and 15.3 of the 7432bis 
draft.

Section 15.2 (which is copied from the parallel section of RFC 
7432) defines 
“sticky” MAC addresses as addresses that are configured as static and therefore 
are not subject to MAC Moves.
It defines how these addresses can be identified, and requires that if such a 
MAC address is seen as the Source MAC address in a locally received Ethernet 
frame, the PE MUST alert the operator. No other actions for this case (be it 
the EVPN CP or EVPN DP actions)  are specified.

[AS] We should add an optional action for dropping such frames. So, we will 
change the sentence to: “If a PE receives such advertisements and later learns 
the same MAC address(es) via local learning, then the PE MUST alert the 
operator and MAY program to drop any received frames with that MAC SA.”

Section 15.3 is a new section that extends the CP mechanisms defined in Section 
15.1 with DP mechanisms breaking Ethernet loops. Such loops can be created by 
backdoor connectivity between L2 customer sites attached to different EVPN PEs.

However, neither these sections nor RFC 9135 seem to discuss the situation when 
an EVPN Broadcast Domain is configured with an IRB and an Ethernet Frame with 
the Source MAC address matching the MAC address of this IRB is locally received 
by one of the PEs in which this Broadcast Domain is instantiated. Such a 
situation may be encountered, e.g., if the EVPN IRB in question is configured 
with anycast MAC address as suggested in Section 4.1 of RFC 
9135, and backdoor 
connectivity exists between different customer sites that are attached to the 
Broadcast Domain in question.

[AS] That is fair and it can happen.

I would highly appreciate your answers to the following questions:

  1.  Should anycast MAC addresses configured on EVPN IRB be treated as 
“sticky”?
[AS] Yes, I think it should and the updated procedure for the sticky MAC 
(highlighted above) can take care of the loop and it can drop the looping 
packets.


  1.  If the answer to the previous question is “Yes”:

 *   Should IP-->MAC pairs of EVPN IRBs be advertised with MAC Mobility 
Extended Community attached and the sticky bit set? To the best of my 
understanding, currently only advertisement with the Default Gateway Extended 
Community attached is required
[AS] Yes.

 *   Should a Broadcast Domain that is used by an EVPN IRB and that locally 
receives an Ethernet frame with the Source MAC address matching the MAC address 
of its IRB perform, in addition to report to the operator, perform any Loop 
Protection actions?
[AS] Yes, per modified sticky MAC address procedure.

Cheers,
Ali

Your timely feedback would be highly appreciated.

IMHO and FWIW it would be nice if your answers (whatever they are) could be 
added in the next revision of the 7432bis draft.

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Secdir telechat review of draft-ietf-bess-bgp-sdwan-usage-15

[Stephen Farrell via Datatracker]

Reviewer: Stephen Farrell
Review result: Has Issues

Roman has covered all the points I would have raised in his dicuss ballot
already, so I'm filing this just for completeness and the authors shouldn't
feel any need to respond to me. In particular though, I've no idea if it's
realistic (or not) to expect the devices envisaged to use a secure transport as
described, but that is covered in Roman's discuss points.


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

Re: [bess] Lars Eggert's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Lars,

Thanks for your review.

I have fixed the issues below (I will submit a revision when I finish 
addressing some comments from others), but have two clarifications - please see 
zzh> below.


Juniper Business Use Only
-Original Message-
From: Lars Eggert via Datatracker 
Sent: Tuesday, October 3, 2023 2:50 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: Lars Eggert's No Objection on 
draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with COMMENT)

[External Email. Be cautious of content]


Lars Eggert has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-12: 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!EupXuCkh2mnHJtnCzM5Y-b7mTyMdfqM0_c75sREZPUhZ5xrIFAXijD3WOxPvCkra7F1NlAkXlmOokW8$
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!EupXuCkh2mnHJtnCzM5Y-b7mTyMdfqM0_c75sREZPUhZ5xrIFAXijD3WOxPvCkra7F1NlAkX9SFzLZk$



--
COMMENT:
--

# GEN AD review of draft-ietf-bess-mvpn-evpn-aggregation-label-12

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review 
(https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/gen-art/3fAtK3w0wRrSeNCGgzBnr86jTRU__;!!NEt6yMaO-gk!EupXuCkh2mnHJtnCzM5Y-b7mTyMdfqM0_c75sREZPUhZ5xrIFAXijD3WOxPvCkra7F1NlAkX96rP7Ns$
 ).

## 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://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!NEt6yMaO-gk!EupXuCkh2mnHJtnCzM5Y-b7mTyMdfqM0_c75sREZPUhZ5xrIFAXijD3WOxPvCkra7F1NlAkX0YAcIcU$
 ), so there will likely be some false positives. There is no need to let me 
know what you did with these suggestions.

### Grammar/style

 Section 1, paragraph 14
```
onal label spaces is to be used to lookup the label, hence those label space
   ^^ ``` The word "lookup" is a noun. The 
verb is spelled with a white space.

 Section 1, paragraph 16
```
referred to as upstream-assigned. Otherwise it is downstream-assigned. An ups
  ^ ``` A comma may be missing after 
the conjunctive/linking adverb "Otherwise".

 Section 2.1, paragraph 5
```
VPN 1, and so forth. Now only 1000 label instead of 1,000,000 labels are nee
   ^ ``` Possible agreement error. The noun 
"label" seems to be countable.

 Section 2.2.1, paragraph 2
```
hen tunnel segmentation is applied to a S-PMSI, certain nodes are "segmentati
  ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

 Section 2.2.2.1, paragraph 1
```
 tunnel T2 and Flow-2 by tunnel T3. Then when the segmentation point receives
 ``` Consider adding a comma here.

 Section 2.2.2.1, paragraph 3
```
 labels for segmented S-PMSI independently from its assigned label block tha
 ^^ ``` The usual collocation for 
"independently" is "of", not "from". Did you mean "independently of"?

Zzh> That "from" goes with the earlier "allocate" not "independently": 
"allocate labels ... from its assigned label block". I changed it to 
"independently allocate labels from ...".

 Section 2.2.2.2, paragraph 1
```
-PMSIs for the same VPN/BD to share the a VPN/BD-identifying label that leads
^ ``` Two determiners in a row. Choose 
either "the" or "a".

 Section 3.2, paragraph 5
```
nel encapsulation of data packets arriving on the tunnel. * They MUST all hav
  ^^^ ``` The usual preposition after 
"arriving" is "at", not "on". Did you mean "arriving at"?

Zzh> I changed it to "via". I feel that "at the tunnel" is a little inaccurate 
(it's really coming out of the tunnel).
Zzh> Thanks!
Zzh> Jeffrey

## 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://urldefense.com/v3/__https://gi

Re: [bess] [Gen-art] Genart last call review of draft-ietf-bess-bgp-sdwan-usage-14

[Lars Eggert]

Dan, thank you for your review. I have entered a Discuss ballot for this 
document based on my own review.

Lars


> On Jul 26, 2023, at 10:15, Dan Romascanu via Datatracker  
> wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Ready with Issues
> 
> 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-bgp-sdwan-usage-14
> Reviewer: Dan Romascanu
> Review Date: 2023-07-25
> IETF LC End Date: 2023-08-01
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Major issues:
> 
> Minor issues:
> 
> 1. As SD-WAN is not an IETF work item, it needs to be better defined, possibly
> by reference. To understand the concept one needs to go to documents external
> to the IETF such as [MEF70.1]. If that is the authoritative reference (or
> there) it should be mentioned in the Introduction section.
> 
> 2. Section 3.1.2
> 
>> The client interface of SD-WAN edges can be IP or Ethernet-based.
> 
> We need a definition or reference (IEEE 802.3 or MEF) of what is meant by
> 'Ethernet-based'.
> 
> Nits/editorial comments:
> 
> In 4.2 and 6.2.1 MEF70.1 needs to be between brackets (Informational 
> Reference)
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[bess] Lars Eggert's Discuss on draft-ietf-bess-bgp-sdwan-usage-15: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-bess-bgp-sdwan-usage-15: 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-bgp-sdwan-usage/



--
DISCUSS:
--

# GEN AD review of draft-ietf-bess-bgp-sdwan-usage-15

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1wTFLnMrWOSsJrziXpMDBcyv6GM).

## Discuss

### Boilerplate

Document has an IETF Trust Provisions (TLP) Section 6.c(i) Publication
Limitation clause. This means it can in most cases not be a WG document.


--
COMMENT:
--

## Comments

### Section 10.1, paragraph 1
```
 [BCP195]  RFC8996, RFC9325.
```
Not really acceptable as a normative reference.

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC8388]`, `[RFC6514]`, `[RFC7988]`, and `[RFC6513]`.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms `traditionally` and `traditional`; alternatives might be `classic`,
   `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`,
   `historic`, `long-established`, `popular`, `prescribed`, `regular`,
   `rooted`, `time-honored`, `universal`, `widely used`, `widespread`
 * Terms `natively` and `native`; alternatives might be `built-in`,
   `fundamental`, `ingrained`, `intrinsic`, `original`

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

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

There is other outdated content in the boilerplate.

### Uncited references

Uncited references: `[MEF70.1]`.

### Outdated references

Document references `draft-ietf-rtgwg-net2cloud-problem-statement-26`, but
`-30` is the latest available revision.

### Grammar/style

 Section 3.1.3, paragraph 5
```
uthorized to communicate with a small number of other SD-WAN edge nodes. In t
  ^
```
Specify a number, remove phrase, use "a few", or use "some". (Also elsewhere.)

 Section 6.2.2, paragraph 6
```
 March 2004. [RFC3947] T. Kivinen, et al, "Negotiation of NAT Traversal in t
   ^
```
A period is misplaced or missing. (Also elsewhere.)

 Section 6.2.2, paragraph 9
```
ov 2021. 11. Acknowledgments Acknowledgements to Andrew Alston, Adrian Farre
 
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

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