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

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]>
Organization: Old Dog Consulting
Reply-To: "[e-mail]" <[e-mail]>
Date: Monday, 17 May 2021 at 16:21
To: Eric Vyncke <[e-mail]>, 'The IESG' <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, 'Matthew Bocci' <[e-mail]>
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