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 <adr...@olddog.co.uk>
Organization: Old Dog Consulting
Reply-To: "adr...@olddog.co.uk" <adr...@olddog.co.uk>
Date: Monday, 17 May 2021 at 16:21
To: Eric Vyncke <evyn...@cisco.com>, 'The IESG' <i...@ietf.org>
Cc: "draft-ietf-bess-datacenter-gate...@ietf.org"
<draft-ietf-bess-datacenter-gate...@ietf.org>, "bess-cha...@ietf.org"
<bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org>, 'Matthew Bocci'
<matthew.bo...@nokia.com>
Subject: RE: Éric Vyncke's No Objection on
draft-ietf-bess-datacenter-gateway-10: (with COMMENT)
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
EV> I rely on the RTG-AD John on whether the resolution below satisfies him
(and it seems so based on the email thread)
>> 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.
EV> actually, you have just recommended/suggested one method: static
configuration by human/SDN controllers
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.
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 --
| 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
EV> it would help indeed
Cheers,
Adrian
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
