Subject: [bess] Éric Vyncke's No Objection on draft-ietf-bess-datacenter-gateway-10: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 17 May 2021 02:04:38 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

I support John Scudder's first DISCUSS point.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

Thanks for Matthew Bocci for his shepherd's write-up (including the WG
consensus).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3 --
How will the GW identifiers be unique across all interconnected SR domains ?
Section 9 is rather hand waving.

-- Section 10 --
Is there any reason why the doc shepherd is not acknowledged ?

== NITS ==

-- Section 1 --
s/against connection of device failure/against connection or device failure/ ?

I find the use of "ingress" in "source (ingress)" confusing, should the reader
assume that it is "source (SR-domain ingress)" ?

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 May 2021 15:21:15 +0100

Hi Eric,

| Thank you for the work put into this document.
|
| I support John Scudder's first DISCUSS point.

Fair enough.

What did you think of my response to John

>> DISCUSS:
>>
>> 1. There’s surprisingly little in this document that seems to be SR-specific
>> (and what there is, has some problems, see below). Is there some reason you
>> rule out interconnecting domains using other tunneling technologies? I ask this
>> question first because if the answer were to be “oh huh, we don’t need to make
>> this SR-specific after all” some of the other things I’m asking about might go
>> away.
>
> I'm sorry this isn't clear, but the use of other tunnelling technologies is very much
> in scope. As the Introduction says:
>
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.
>
> SR is used to identify the tunnels and provide end-to-end SR paths because the
> ingress and egress domains are SR domains, and the objective is to provide an
> end-to-end SR path.
>
> So we are not "making this SR aware" so much as enabling "SR-over-foo" using
> SIDs to identify the path segments that are tunnels.
>
> I don't know how to make this clearer except maybe using some red paint. We
> would write...
>
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.  That is, the
>   Ingress and Egress SR Domains can be connected by tunnels across a
>   variety of technologies.  This document describes how SR identifiers
>   (SIDs) are used to identify the paths between the Ingress and Egress
>   and the techniques in this document apply to routes of all AFI/SAFIs.

| Please find below some non-blocking COMMENT points (but replies
| would be appreciated), and some nits.
|
| == COMMENTS ==
|
| -- Section 3 --
| How will the GW identifiers be unique across all interconnected SR domains ?
| Section 9 is rather hand waving.

There are two issues to be resolved:
1. How will all interconnected SR sites (formerly called domains) use different site identifiers?
2. How will all gateways to the same site consistently use the same identifier?

Just like the mechanisms used to assign many other things in networking (IP addresses, AS numbers, VPN IDs, ...) there may be many approaches available (dedicated protocols, piggy-backing on other protocols, management protocols, manual configuration).

Not sure why this spec needs to be responsible for defining those distribution/configuration/coordination mechanisms.

Section 9 makes it very clear what result must be achieved, and observes that we are not introducing a new problem to the BGP world.

Could we make it clearer that the operator is responsible for getting this right?

| -- Section 10 --
| Is there any reason why the doc shepherd is not acknowledged ?

Of course, we love our shepherd. 
Matthew, as WG chair, pushed the right people to do reviews, and also pushed the right buttons to advance the document.
As shepherd, Matthew wrote: I reviewed Version 8 of the draft. I have no significant comments on the draft. 

The Acknowledgements section historically thanks people whose comments have helped shape or improve the contents of the document.

| == NITS ==
|
| -- Section 1 --
| s/against connection of device failure/against connection or device failure/ ?

Ack

| I find the use of "ingress" in "source (ingress)" confusing, should the reader
| assume that it is "source (SR-domain ingress)" ?

Could write "source DC (also known as an ingress DC)"
Ditto destination/egress

Cheers,
Adrian

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 19 May 2021 15:19:25 +0000

Hello Adrian,

Thank you for your reply. As you know all my comments are non-blocking, please have a look below for EV>

Regards,

-éric

-----Original Message-----
From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, 17 May 2021 at 16:21
To: Eric Vyncke <[email-masked]>, 'The IESG' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'Matthew Bocci' <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-bess-datacenter-gateway-10: (with COMMENT)

    Hi Eric,

    Fair enough.

EV> I rely on the RTG-AD John on whether the resolution below satisfies him (and it seems so based on the email thread)

EV> actually, you have just recommended/suggested one method: static configuration by human/SDN controllers

    | -- Section 10 --

EV> FYI, the IESG wants to provide incentive for being a doc shepherd or a directorate reviewer. I.e., the shepherd is expected to do a lot of leg work for the document and a serious in-depth review by a directorate reviewer is important even if the review can be summarized as a simple 'good to go', the effort is worthwhile IMHO (even is the quality of reviews can vary)

    | == NITS ==
    |
    | -- Section 1 --

    Ack

EV> it would help indeed

    Cheers,
    Adrian