Skip to main content

Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing
RFC 9125

Revision differences

Document history

Date Rev. By Action
2022-03-31
13 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2021-08-28
13 (System)
Received changes through RFC Editor sync (created alias RFC 9125, changed title to 'Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing', …
Received changes through RFC Editor sync (created alias RFC 9125, changed title to 'Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing', changed abstract to 'Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load-balancing, and resiliency reasons. Other sites, such as access networks, also need to be connected across backbone networks through gateways.

This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow data center gateway routers to advertise routes to the prefixes reachable in the site, including advertising them on behalf of other gateways at the same site. This allows segment routing to be used to identify multiple paths across the Internet or backbone network between different gateways. The paths can be selected for load-balancing, resilience, and quality purposes.', changed pages to 12, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-08-28, changed IESG state to RFC Published)
2021-08-28
13 (System) RFC published
2021-08-24
13 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9125">AUTH48-DONE</a> from AUTH48
2021-08-21
13 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9125">AUTH48</a>
2021-08-05
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-07-28
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-07-28
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-07-28
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-07-28
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-07-28
13 (System) RFC Editor state changed to EDIT
2021-07-28
13 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-07-28
13 (System) Announcement was received by RFC Editor
2021-07-28
13 (System) IANA Action state changed to In Progress
2021-07-28
13 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-07-28
13 Amy Vezza IESG has approved the document
2021-07-28
13 Amy Vezza Closed "Approve" ballot
2021-07-28
13 (System) Removed all action holders (IESG state changed)
2021-07-28
13 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-07-28
13 Martin Vigoureux Ballot approval text was generated
2021-07-22
13 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-13.txt
2021-07-22
13 (System) Forced post of submission
2021-07-22
13 (System)
Request for posting confirmation emailed to previous authors: Adrian Farrel <adrian@olddog.co.uk>, Eric Rosen <erosen52@gmail.com>, John Drake <jdrake@juniper.net>, Keyur Patel …
Request for posting confirmation emailed to previous authors: Adrian Farrel <adrian@olddog.co.uk>, Eric Rosen <erosen52@gmail.com>, John Drake <jdrake@juniper.net>, Keyur Patel <keyur@arrcus.com>, Luay Jalil <luay.jalil@verizon.com>
2021-07-22
13 Adrian Farrel Uploaded new revision
2021-07-21
12 Benjamin Kaduk
[Ballot comment]
The -12 does address the discuss point that I raised, thank you!

In re-reading the draft so as to clear my discuss position, …
[Ballot comment]
The -12 does address the discuss point that I raised, thank you!

In re-reading the draft so as to clear my discuss position, one thing
that occurred to me is that a reader might wonder what mechanisms are in
place to prevent an attacker outside of a site from spoofing an
auto-discovery route with a given site's site identifier.  (The security
considerations already dutifully considers the case of a node in the
site that is not a gateway being able to falsify an auto-discovery
route.)  As far as I can tell this is not an issue because nodes in the
site will not accept auto-discovery routes that initiate from outside
the site, based on configured knowledge of whether a given BGP peering
is internal or external.  The document already makes some allusions to
this by specifying that the actual tunnel encapsulation with the union
of all GWs' data is only included in "every route advertised externally
to that site", implying that the auto-discovery routes are on the
non-external (i.e., internal) advertisements.  It might (or might not)
be worth being more explicit about auto-discovery only occuring
internally within a site, to clarify this mechanism of action.

NITS

Section 1

  Data centers (DCs) are critical components of the infrastructure used
  by network operators to provide services to their customers.  DCs
  (sites) are interconnected by a backbone network, which consists of
  any number of private networks and/or the Internet, by gateway
  routers (GWs).  [...]

This currently looks like "interconnected by <X> (...), by <Y>" which
doesn't seem right.  Maybe end the sentence after "and/or the Internet"
and finish with "Each DC is connected to the backbone by one or more
gateway routers (GWs)"?

  The solution described in this document is agnostic as to whether the
  transit ASes do or do not have SR capabilities.  the solution uses SR
  to stitch together path segments between GWs and through the ASBRs.

Start the sentence with a majuscule 'T'.

  technique will experience scaling issues.  This all means that the
  Add-Paths approach is limited to sites connected over a single AS.

I'd consider "effectively limited"; we know that some groups/individuals
have a high capacity for hitting themselves in the way that recursive
Add-Path would entail.
2021-07-21
12 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-06-11
12 Roman Danyliw
[Ballot comment]
Thank you to Daniel Migault for the SECDIR review.

Thanks for addressing my DISCUSS by adding new language about the need to secure …
[Ballot comment]
Thank you to Daniel Migault for the SECDIR review.

Thanks for addressing my DISCUSS by adding new language about the need to secure the traffic via encrypted tunnels when traversing untrusted networks.

I support John's DISCUSS position.
2021-06-11
12 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2021-06-07
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-06-07
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-06-07
12 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-12.txt
2021-06-07
12 (System) New version accepted (logged-in submitter: Adrian Farrel)
2021-06-07
12 Adrian Farrel Uploaded new revision
2021-06-01
11 John Scudder
[Ballot comment]
Thanks for addressing my Discuss.


1. Abstract

  This document defines a mechanism using the BGP Tunnel Encapsulation
  attribute to allow each …
[Ballot comment]
Thanks for addressing my Discuss.


1. Abstract

  This document defines a mechanism using the BGP Tunnel Encapsulation
  attribute to allow each gateway router to advertise the routes to the
  prefixes in the Segment Routing domains to which it provides access,
  and also to advertise on behalf of each other gateway to the same
  Segment Routing domain.

The last clause has no object. To advertise WHAT? Possibly (?) it could be rewritten “... provides access, including advertising them on behalf of...”

2. Section 1

  against connection of device failure.

“Of” -> “or”

3. Section 3

  o  A route target ([RFC4360]) is attached to each GW's auto-discovery
      route and has its value set to the SR domain identifier.

Insert “(defined below)” after “auto-discovery route”, please?

  The auto-discovery route that each GW advertises consists of the
  following:

The use of the definite article implies that each GW can advertise one, and only one, auto-discovery route. Is this true?

4. Section 5

  When a packet destined for prefix X is sent on an SR TE path to a GW
  for the SR domain containing X (that is, the packet is sent in the
  Ingress Domain on an SR TE path that describes the path including
  within the Egress Domain), it needs to carry the receiving GW's label

I can’t understand the parenthetical, in particular “the path including within the Egress Domain”.

Also, do you really mean “label”, or do you mean “SID”? I don’t think you scoped this to only SR-MPLS, did you? Although reading on within §5 you talk about the “label stack”, so it does appear you’re MPLS specific — probably this should be said up front, in that case? The title should really be “… for SR-MPLS Enabled Domain Interconnection”?

5. Section 6

  If the GWs for a given SR domain are configured to allow remote GWs
  to send them a packet in that SR domain's native encapsulation, then

This is forbidden by RFC 8402, see my discuss comment #3. Maybe this is just an easy terminology fix, or maybe not.

6. Section 8

  All of the issues in the list above could cause disruption to domain
  interconnection, but are not new protocol vulnerabilities so much as
  new exposures of information that SHOULD be protected against using
  existing protocol mechanisms.  Furthermore, it is a general

What are the existing BGP protocol mechanisms that could be used to protect against exposure of information? BGP itself doesn’t have any confidentiality features nor do most of its common transports. Maybe you mean something different, but if so that’s not clear to me.

  system.  It should be noted that BGP peerings are not discovered, but
  always arise from explicit configuration.

This is true at present, but IDR has work in progress on autodiscovery. (Same comment applies with respect to Section 9.)

7. Section 9.1

  consideration.  When using the mechanisms defined in this document,
  the operator should consider carefully the effects of filtering
  routes.  In some cases this may be desirable, and in others it could
  limit the effectiveness of the procedures.

I believe the only use of route targets in this document is for the autodiscovery routes.  If RTC were in use, through its normal operation the gateways would exchange autodiscovery routes exactly as this specification needs them to. So your cryptic warning above leaves me wondering, what are the cases in which RTC impedes the function of the specification?

8. General

The autodiscovery mechanism is clear as far as it goes, but I think not all failure modes are addressed. In particular, if there’s partial connectivity within a domain, I think long-term black holing can ensue. Consider this case: GW1 and GW2 are gateways in domain A. GW3 is a gateway in domain B. GW1 and GW2 discover one another and advertise one another’s encapsulation information accordingly, when advertising a route to prefix X. However, there’s a problem within GW1 and GW2’s domain, such that GW1 can reach X, but GW2 can’t. Even though GW2 may know it can’t reach X, and indeed GW2 isn’t advertising X, GW1 is still advertising GW2 as a viable gateway to reach X, and GW3 may well route traffic for X via GW2.

Admittedly, having partial connectivity within a domain as I’ve described is a broken situation to begin with, but stuff happens, and your spec would make matters worse. It might be worth acknowledging this issue somewhere in the document?
2021-06-01
11 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2021-05-27
11 Warren Kumari
[Ballot comment]
I am changing my previous DISCUSS to a No Objection; I was planning on Abstain, but after yet more thought I think No …
[Ballot comment]
I am changing my previous DISCUSS to a No Objection; I was planning on Abstain, but after yet more thought I think No Objection is the best position.

Background:
When thinking about this document I still feel disquiet (actually "heebie-jeebies" is probably a better description!), but it's not actually **this** document which is causing me concern, it is rather RFC8402 (and the fact that this facilitates /propagates its use).  I still feel like stamping my feet and throwing all of my toys out the cot, but my grump cannot realistically be pointed at this draft.


I'd also like to recognize that Adrian Farrel did a great job on talking me down from my ledge. I was filled with righteous indignation, and his helpful and friendly tone helped me understand and process my thoughts; this directly led to my willingness to change. Thank you everyone.
2021-05-27
11 Warren Kumari Ballot comment text updated for Warren Kumari
2021-05-27
11 Warren Kumari
[Ballot comment]
I am changing my previous DISCUSS to a No Objection. I was planning on Abstain, but after yet more thought I think No …
[Ballot comment]
I am changing my previous DISCUSS to a No Objection. I was planning on Abstain, but after yet more thought I think No Objection is the best postition.

Background:
When thinking about this document I still feel disquiet (actually "heebie-jeebies" is probably a better description!), but it's not actually **this** document which is causing me concern, it is rather RFC8402, and the fact that this facilitates its use. I'd like to still be able to stamp me feet and throw all of my toys out the cot about *this* document, but it would be misplaced...

I'd also like to note that Adrian Farrel did a great job on talking me down from my ledge. I was filled with righteous indignation, and his helpful and friendly tone helped me understand and process my thoughts. I (and the authors/WG) owe him thanks...
2021-05-27
11 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2021-05-24
11 Benjamin Kaduk
[Ballot discuss]
Thanks for having the discussion with John and updating the document
already; I benefitted a lot from being able to read the -11 …
[Ballot discuss]
Thanks for having the discussion with John and updating the document
already; I benefitted a lot from being able to read the -11 that has
started rolling in fixes from the prior discussion.  My one new discuss
point is relatively minor, all things considered, and is really just
trying to nail down an aspect of internal consistency.  (I also support
Roman's disuss, but we don't need to rehash that here.)

When we introduce the concept of gateways, we say that they can be
attached to the Internet or a backbone network.  We then go on to
provide a mechanism for gateways to advertise to some tunnel ingress
node the complete set of gateways for a given site.  It seems that we do
fairly consistently refer to this advertisement as being over "the
backbone network", but I'm not seeing anything that clearly disclaims
the applicability of this technique over the Internet itself.  However,
I think we need to have such a disclaimer, since we do have a clearly
stated assumption that "the connected set of DCs *and the backbone
network connecting them* are part of the same SR BGP Link State (LS)
instance ([RFC7752] and [I-D.ietf-idr-bgpls-segment-routing-epe])"
(emphasis mine).  If the intent is to only use this mechanism over
"in-BGP-LS-instance" backbones and not over the Internet, we should
explicitly set the scope of applicability and contrast a gateway as a
generic concept and the gateway scenarios that this mechanism applies
to.
2021-05-24
11 Benjamin Kaduk
[Ballot comment]
Thanks to Daniel Migault for the secdir review, and to the authors for
the updates in response to it.

The Abstract is perhaps …
[Ballot comment]
Thanks to Daniel Migault for the secdir review, and to the authors for
the updates in response to it.

The Abstract is perhaps pushing the bounds of reasonable length for an
abstract.  Perhaps:

% This document defines a mechanism using the BGP Tunnel Encapsulation
% attribute to allow datacenter gateway routers to advertise routes to the
% prefixes reachable in the site, including advertising them on behalf of
% other gateways at the same site.  This allows for multiple paths across
% the Internet or backbone (terminating at the different gateways) to be
% used by segment routing to steer traffic for load-balancing and
% resiliency purposes.

Section 1

  The solution described in this document is agnostic as to whether the
  transit ASes do or do not have SR capabilities.  the solution uses SR
  to stitch together path segments between GWs and through the ASBRs.
  Thus, there is a requirement that the GWs and ASBRs are SR-capable.
  The solution supports the SR path being extended into the ingress and
  egress sites if they are SR-capable.

There seem to be some nodes marked "ASBR" that are at the boundary
between the two transit ASes, in Figure 1.  This text leaves me
uncertain whether they are expected to support SR (vs just the ASBRs
that are attachment points for the ingress/egress GWs).

Section 3

  o  Each GW is configured with an identifier for the site.  That
      identifier MUST be the same across all GWs to the site (i.e., the
      same identifier is used by all GWs to the same site), and MUST be
      unique across all sites that are connected (i.e., across all GWs
      to all sites that are interconnected).

The advice in draft-gont-numeric-ids-sec-considerations is probably
relevant here.  How should we pick these identifiers?  Which properties
are necessary and which are not needed?

  o  Each GW MUST construct an import filtering rule to import any
      route that carries a route target with the same site identifier
      that the GW itself uses.  This means that only these GWs will
      import those routes, and that all GWs to the same site will import
      each other's routes and will learn (auto-discover) the current set
      of active GWs for the site.

This seems pretty fragile in the face of identifier collisions; I hope
there is some good text in the security considerations that covers the
risks here.
[ed. it seems we cover other aspects relating to identifier selection
but not this one]
Is there any filtering that can be done other than by site identifier,
e.g., to know that a certain peer would never be able to advertise
something that validly has the same site identifier?

  As described in Section 1, each GW will include a Tunnel
  Encapsulation attribute with the GW encapsulation information for
  each of the site's active GWs (including itself) in every route
  advertised externally to that site.  [...]

(I assume this is not intended to preclude the usual route
filtering/split-horizon type stuff.)

                                        As the current set of active GWs
  changes (due to the addition of a new GW or the failure/removal of an
  existing GW) each externally advertised route will be re-advertised
  with a new Tunnel Encapsulation attribute which reflects current set
  of active GWs.

The "everybody advertises the union of what they've seen" behavior seems
like it will latch NLRI in place as being a GW, but here we're saying
that removal will be propagated as well as addition.  What's the
mechanism for removing stale data (whether maliciously added or as part
of maintenance?  If it's an explicit withdrawl, is that also propagated
by everybody?  How long does it have to stay around for?  (I recognize
that some of this is just stock BGP, but I am looking for more clarity
on how it interacts with the "advertise the union of what you saw"
behavior that is new to this document.  The text in the next paragraph
mentions that there can be situations with broken internal routing where
things land in a broken state -- how long do they stay broken and how
can they be fixed?

  If a gateway becomes disconnected from the backbone network, or if
  the site operator decides to terminate the gateway's activity, it
  MUST withdraw the advertisements described above.  This means that
  remote gateways at other sites will stop seeing advertisements from
  this gateway.  Note that if the routing within a site is broken (for
  example, such that there is a route from one GW to another, but not
  in the reverse direction), then it is possible that incoming traffic
  will be routed to the wrong GW to reach the destination prefix - in
  this degraded network situation, traffic may be dropped.

This is probably worth reiterating in the security considerations
section.

  Note that if a GW is (mis)configured with a different site identifier
  from the other GWs to the same site then it will not be auto-
  discovered by the other GWs (and will not auto-discover the other
  GWs).  This would result in a GW for another site receiving only the
  Tunnel Encapsulation attribute included in the BGP best route; i.e.,
  the Tunnel Encapsulation attribute of the (mis)configured GW or that
  of the other GWs.

Are there noteworthy operational considerations of this, e.g., if all
the traffic gets directed to a GW that lacks the bandwidth to handle it?

Section 4

  attribute to identify the GWs through which X can be reached.  It
  uses this information to compute SR Traffic Engineering (SR TE) paths
  across the backbone network looking at the information advertised to
  it in SR BGP Link State (BGP-LS)

This seems to leave the reader wondering about the details of how those
SR TE paths are computed.  I understand that it's properly out of scope
for this document, but a reference would go a long way.

Section 5

  for a prefix X, then each GW computes an SR TE path through that site
  to X from each of the currently active GWs, and places each in an
  MPLS label stack sub-TLV [RFC9012] in the SR Tunnel TLV for that GW.

I don't think I understand why each (egress) GW has to (re)compute the
path through the site to X for each of the GWs at the site -- can't it
just take the sub-TLV it got from the peer and re-propagate it?

Section 6

[The topic of which sites are allowed to send in the site's native
encapsulation seems related to questions of what an "SR Domain" is and
what boundary security it has.  I think that the other ADs are basically
covering this topic, though, so am not sure there is much more to say
here.]

  If the GWs for a given site are configured to allow remote GWs to
  send them a packet in that site's native encapsulation, then each GW
  will also include multiple instances of a Tunnel TLV for that native
  encapsulation in externally advertised routes: one for each GW and
  each containing a Tunnel Egress Endpoint sub-TLV with that GW's
  address.  [...]

Does this implicitly require that all the GWs of the site have the same
configuration for whether or not to allow native encapsulation from
remote GWs?  How would things degrade if a mixed configuration did
happen to occur?

Section 8

  From a protocol point of view, the mechanisms described in this
  document can leverage the security mechanisms already defined for
  BGP.  Further discussion of security considerations for BGP may be
  found in the BGP specification itself [RFC4271] and in the security
  analysis for BGP [RFC4272].  The original discussion of the use of
  the TCP MD5 signature option to protect BGP sessions is found in
  [RFC5925], while [RFC6952] includes an analysis of BGP keying and
  authentication issues.

Such an elegant way of not mentioning TCP-AO :)
(I do see that it is actually referenced, just not mentioned by name.)

The whole section is quite nicely done, actually -- thank you!

Section 11

I don't really understand why draft-ietf-idr-bgpls-segment-routing-epe
is listed as normative but draft-ietf-idr-bgp-ls-segment-routing-ext is
listed as informative.  They seem to be used in the same place.

NITS/EDITORIAL

Section 1

  two DC sites.  In order for a source DC (also known as an ingress DC)
  that uses SR to load balance the flows it sends to a destination DC

I'd consider "also known as an ingress DC since it forms the ingress
endpoint of a tunnel".

  sites 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

FWIW I don't think I figured out what "MPLS with global table routing
native BGP to the edge" means with any real confidence, and my attempts
to google it basically just found this document.  So please feel
encouraged to take another look at the phrasing.  My current most-likely
interpretation is that there is internally MPLS with global table, but
that what's presented to the outside is native BGP-based IP routing, so
there's some implied translation layer.

Section 3

  To avoid the side effect of applying the Tunnel Encapsulation
  attribute to any packet that is addressed to the GW itself, the GW
  MUST use a different loopback address for packets intended for it.

"different" is most clear when we list both things that differ.
So perhaps it's safer to say that the address advertised for
auto-discovery must use a different loopback address than is advertised
for packets directed to the gateway itself.

Section 5

  achieve this, each Tunnel TLV in the Tunnel Encapsulation attribute
  contains a Prefix SID sub-TLV [RFC9012] for X.  As defined in
  [RFC9012], the Prefix SID sub-TLV is only for IPv4/IPV6 labelled

I wonder if this sentence break should really be a paragraph break,
since the following paragraph seems to cover MPLS in a way that roughly
parallels how we treat IP here.

  applies to routes of those types.  If the use of the Prefix SID sub-
  tlv for routes of other types is defined in the future, further
  documents will be needed to describe their use.

I think that we are missing a "for SR TE tunnel encapsulation" at the
end, as the current text is basically saying "if the use of X is defined
in the future, future documents will be needed to describe the use of
X", which is fairly devoid of content.

  Alternatively, if MPLS SR is in use and if the GWs for a given site
  are configured to allow remote GWs to perform SR TE through that site
  for a prefix X, then each GW computes an SR TE path through that site

We might benefit from sprinkling around some "ingress" and "egress"
here.
2021-05-24
11 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-05-20
11 (System) Changed action holders to Adrian Farrel, Keyur Patel, Martin Vigoureux, John Drake, Eric Rosen, Luay Jalil (IESG state changed)
2021-05-20
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-05-20
11 Murray Kucherawy
[Ballot comment]
Thanks for the nice work on that shepherd writeup.

Why is the SHOULD in Section 8 only a SHOULD?  Why might I legitimately …
[Ballot comment]
Thanks for the nice work on that shepherd writeup.

Why is the SHOULD in Section 8 only a SHOULD?  Why might I legitimately not do what it says?
2021-05-20
11 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-05-19
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-05-19
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-05-19
11 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-11.txt
2021-05-19
11 (System) New version accepted (logged-in submitter: Adrian Farrel)
2021-05-19
11 Adrian Farrel Uploaded new revision
2021-05-19
10 Roman Danyliw [Ballot comment]
Thank you to Daniel Migault for the SECDIR review.

I support John's DISCUSS position.
2021-05-19
10 Roman Danyliw Ballot comment text updated for Roman Danyliw
2021-05-19
10 Roman Danyliw
[Ballot discuss]
RFC8402 tells us:

(a)“Segment Routing domain (SR domain): the set of nodes participating in the source-based routing model … 

(a.1) “These nodes may …
[Ballot discuss]
RFC8402 tells us:

(a)“Segment Routing domain (SR domain): the set of nodes participating in the source-based routing model … 

(a.1) “These nodes may be connected to the same physical infrastructure (e.g., a Service Provider's network).”

(a.2) “They may as well be remotely connected to each other (e.g., an  enterprise VPN or an overlay).”

(b) “By default, SR operates within a trusted domain.  Traffic MUST be filtered at the domain boundaries.”
My understanding of this document is that it is an enabling capability to help establish SR domains of the like described in (a.2).  What I see missing is text that provides the confidence suggested by the language of “trusted domain” in (b).

-- Section 1 hints at various VPN technologies perhaps being used  “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.”  However, the security properties of all of those aren’t clear to a degree that would seem consistent with being a “trusted domain”.  For example, saying “IP” might suggest that naked IP packets with SR headers (with no additional security primitives) could be dropped onto the open Internet, or at least through networks not under the control the “data centers” use case suggested by the name of the document. 

-- The discussion at https://mailarchive.ietf.org/arch/msg/bess/zY783PgnXSCp6GNSRF4kY0diLYs/ around the forwarding plane trust model is also informative.  It is noted that that the “transit nodes of the AS are not part of the domain.”  I could agree, but only to the degree that the SR packets are tunneled in such as way that suggested a trusted domain at least of equal security as (a.1).

I think language is needed to describe the normative security requirements of the tunnels that will be created on top of the routes enables by this work to substantiate the claim that at a “trusted domain” is being maintained.  This has some overlap with John’s text about clarify the proposed trust model.
2021-05-19
10 Roman Danyliw [Ballot comment]
Thank you to Daniel Migault for the SECDIR review.

I support John DISCUSS positions.
2021-05-19
10 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2021-05-19
10 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document.

The draft has a manageability considerations section - thanks - but I would like to check whether assignment …
[Ballot comment]
Hi,

Thanks for this document.

The draft has a manageability considerations section - thanks - but I would like to check whether assignment of the SR domain identifier would expect to be configured via YANG?  If so, is there a YANG data model in the works that will cover this functionality?  Having an informational reference to the data model may be helpful to readers.

Regards,
Rob
2021-05-19
10 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-05-18
10 Warren Kumari
[Ballot discuss]
I hope that I'm just misunderstanding something obvious, but I strongly support John's DISCUSS -- when SR was "approved" it was with the …
[Ballot discuss]
I hope that I'm just misunderstanding something obvious, but I strongly support John's DISCUSS -- when SR was "approved" it was with the understanding that it would only be used within "real" limited domains, and would never be sent outside of closed/limited network.

The document says: "The solution defined in this document can be seen in the broader context of SR domain interconnection in [I-D.farrel-spring-sr-domain-interconnect]. ", which says: " Traffic originating in one SR domain often terminates in another SR domain, but must transit a backbone network that provides interconnection between those domains." -- is it unclear to me if this is really what is being proposed...

I'm hoping that I'm really misunderstanding something here -- please educate me.
2021-05-18
10 Warren Kumari Ballot discuss text updated for Warren Kumari
2021-05-18
10 Warren Kumari
[Ballot discuss]
I hope that I'm just misunderstanding something obvious, but I strongly support John's DISCUSS -- when SR was "approved" it was with the …
[Ballot discuss]
I hope that I'm just misunderstanding something obvious, but I strongly support John's DISCUSS -- when SR was "approved" it was with the understanding that it would only be used within "real" limited domains, and would never be sent outside of closed/limited network.

The document says: "The solution defined in this document can be seen in the broader context of SR domain interconnection in [I-D.farrel-spring-sr-domain-interconnect]. ", which says: " Traffic originating in one SR domain often terminates in another SR domain, but must transit a backbone network that provides interconnection between those domains." -- is it unclear to me if this is really what is being proposed...
2021-05-18
10 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2021-05-18
10 Lars Eggert
[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as …
[Ballot comment]
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.

Section 1, paragraph 8, nit:
> e BGP feature that allows the advertisement of multiple paths in BGP (known a
>                              ^^^^^^^^^^^^^^^^
The usual collocation for "advertisement" is "for", not "of". Did you mean
"advertisement for"?

Section 1, paragraph 10, nit:
> oute advertised by a GW identifies all of the GWs to the same SR domain (see
>                                    ^^^^^^^^^^
Consider using "all the".

Section 3, paragraph 12, nit:
> ulation attribute included in the BGP best route; i.e., the Tunnel Encapsula
>                                  ^^^^^^^^^^^
A determiner is probably missing here: "BGP the best".

Section 4, paragraph 1, nit:
> State and Egress Peer Engineering When a remote GW receives a route to a pre
>                                  ^^^^
"When" at the beginning of a sentence usually requires a 2nd clause. Maybe a
comma, question or exclamation mark is missing, or the sentence is incomplete
and should be joined with the following sentence.

Section 8, paragraph 6, nit:
> he AS that hosts the domain) can see all of the gateways to a site. For examp
>                                      ^^^^^^^^^^
Consider using "all the".

Section 8, paragraph 8, nit:
> in black-holing of traffic. All of the issues in the list above could cause
>                            ^^^^^^^^^^
Consider using "all the".

Section 11.2, paragraph 9, nit:
> hen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911,
>                          ^^^^^^^^^^^^^^^^
The usual collocation for "Advertisement" is "for", not "of". Did you mean
"advertisement for"?

Document still references draft-ietf-idr-tunnel-encaps, but that has been
published as RFC9012.

Document still references draft-ietf-idr-bgp-ls-segment-routing-ext-16, but -18
is the latest available revision.
2021-05-18
10 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-05-17
10 Erik Kline
[Ballot comment]
[[ comments ]]

[ section 8 ]

* My understanding is that this will allow a packet from "Ingress" with an
  SRH …
[Ballot comment]
[[ comments ]]

[ section 8 ]

* My understanding is that this will allow a packet from "Ingress" with an
  SRH that includes SRv6 SIDs associated with either GW1 or GW2 in "Egress".

  RFC 8754 (sections 5.1 and 7) discusses the necessity to filter SRH packets
  at the SR domain ingress point.  If my understanding above is correct, I
  think it could be more clear that deliberately not filtering SRH at the
  domain boundaries is a choice being made here which, further, may have
  consequences of the sort described in RFC 5095.

  But maybe I've misunderstood.
2021-05-17
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-05-17
10 Alvaro Retana
[Ballot comment]
The concept of an "SR domain identifier" is not part of rfc8402; it is casually introduced in §3: "A route target ([ …
[Ballot comment]
The concept of an "SR domain identifier" is not part of rfc8402; it is casually introduced in §3: "A route target ([RFC4360]) is attached to each GW's auto-discovery route and has its value set to the SR domain identifier."  This is a significant change to the SR architecture.

In line with the general use of the mechanism in this document (from John's DISCUSS), I believe it is unnecessary to add anything new to the SR architecture.  Instead, the term could be changed to simply "local domain identifier" (or something like that).
2021-05-17
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-05-17
10 Éric Vyncke
[Ballot 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 …
[Ballot 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)" ?
2021-05-17
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-05-14
10 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-05-13
10 John Scudder
[Ballot discuss]
I have several points I’d like to discuss, listed below from most general to most specific.

1. There’s surprisingly little in this document …
[Ballot discuss]
I have several points I’d like to discuss, listed below from most general to most specific.

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.

2. There’s no discussion about what trust model you’re assuming. SR brings with it its own assumed trust model, laid out in RFC 8402 as “SR operates within a trusted domain” (whatever *that* means). On the one hand, given you’re tying yourself to SR you presumably are tied to its trust model. On the other hand, there are some tantalizing tidbits that suggest otherwise. I would be happier if there were some explicit description of the trust model you’re presuming. It’s hard to evaluate some aspects of the document without knowing if you’re assuming the RFC 8402 closed domain model, or something else.

3. The use of the term “SR domain” in this document appears inconsistent with its definition in RFC 8402. Here’s that definition, from §2:

  Segment Routing domain (SR domain): the set of nodes participating in
  the source-based routing model.  These nodes may be connected to the
  same physical infrastructure (e.g., a Service Provider's network).
  They may as well be remotely connected to each other (e.g., an
  enterprise VPN or an overlay).  If multiple protocol instances are
  deployed, the SR domain most commonly includes all of the protocol
  instances in a network.  However, some deployments may wish to
  subdivide the network into multiple SR domains, each of which
  includes one or more protocol instances.  It is expected that all
  nodes in an SR domain are managed by the same administrative entity.

And notably, later in 8402 §8 we are told that

  By default, SR operates within a trusted domain.  Traffic MUST be
  filtered at the domain boundaries.

Which specifically means, to take the MPLS instantiation of SR (§8.1):

  SR domain boundary routers MUST filter any external traffic destined
  to a label associated with a segment within the trusted domain.  This
  includes labels within the SRGB of the trusted domain, labels within
  the SRLB of the specific boundary router, and labels outside either
  of these blocks.  External traffic is any traffic received from an
  interface connected to a node outside the domain of trust.

More simply put, 8402 says you can’t send an SR packet from outside an SR domain, into that domain. But your document is written in terms of a multiplicity of SR domains, for example this in Section 1:

  Tunnel Encapsulation attribute.  The gateway in the ingress SR domain
  can now see all possible paths to X in the egress SR domain

Maybe a quick fix, assuming you really do subscribe to the RFC 8402 trust model, is to invent, define, and use the term “SR subdomain” and deem all the subdomains to comprise one SR domain, in the sense of RFC 8402 §2 — “They may as well be remotely connected to each other (e.g., an enterprise VPN or an overlay)” seems to describe your situation pretty well.
2021-05-13
10 John Scudder Ballot discuss text updated for John Scudder
2021-05-13
10 John Scudder
[Ballot discuss]
I have several points I’d like to discuss, listed below from most general to most specific.

1. There’s surprisingly little in this document …
[Ballot discuss]
I have several points I’d like to discuss, listed below from most general to most specific.

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.

2. There’s no discussion about what trust model you’re assuming. SR brings with it its own assumed trust model, laid out in RFC 8402 as “SR operates within a trusted domain” (whatever *that* means). On the one hand, given you’re tying yourself to SR you presumably are tied to its trust model. On the other hand, there are some tantalizing tidbits that suggest otherwise. I would be happier if there were some explicit description of the trust model you’re presuming. It’s hard to evaluate some aspects of the document without knowing if you’re assuming the RFC 8402 closed domain model, or something else.

3. The use of the term “SR domain” in this document appears inconsistent with its definition in RFC 8402. Here’s that definition, from §2:

  Segment Routing domain (SR domain): the set of nodes participating in
  the source-based routing model.  These nodes may be connected to the
  same physical infrastructure (e.g., a Service Provider's network).
  They may as well be remotely connected to each other (e.g., an
  enterprise VPN or an overlay).  If multiple protocol instances are
  deployed, the SR domain most commonly includes all of the protocol
  instances in a network.  However, some deployments may wish to
  subdivide the network into multiple SR domains, each of which
  includes one or more protocol instances.  It is expected that all
  nodes in an SR domain are managed by the same administrative entity.

And notably, later in 8402 §8 we are told that

  By default, SR operates within a trusted domain.  Traffic MUST be
  filtered at the domain boundaries.

Which specifically means, to take the MPLS instantiation of SR (§8.1):

  SR domain boundary routers MUST filter any external traffic destined
  to a label associated with a segment within the trusted domain.  This
  includes labels within the SRGB of the trusted domain, labels within
  the SRLB of the specific boundary router, and labels outside either
  of these blocks.  External traffic is any traffic received from an
  interface connected to a node outside the domain of trust.

More simply put, 8402 says you can’t send an SR packet from outside an SR domain, into that domain. But your document is written in terms of a multiplicity of SR domains, for example this in Section 1:

  Tunnel Encapsulation attribute.  The gateway in the ingress SR domain
  can now see all possible paths to X in the egress SR domain

Maybe a quick fix, assuming you really do subscribe to the RFC 8402 trust model, is to invent, define, and use the term “SR subdomain” and deem all the subdomains to be one SR domain, in the sense of RFC 8402 §2 — “They may as well be remotely connected to each other (e.g., an enterprise VPN or an overlay)” seems to describe your situation pretty well.
2021-05-13
10 John Scudder
[Ballot comment]
1. Abstract

  This document defines a mechanism using the BGP Tunnel Encapsulation
  attribute to allow each gateway router to advertise the …
[Ballot comment]
1. Abstract

  This document defines a mechanism using the BGP Tunnel Encapsulation
  attribute to allow each gateway router to advertise the routes to the
  prefixes in the Segment Routing domains to which it provides access,
  and also to advertise on behalf of each other gateway to the same
  Segment Routing domain.

The last clause has no object. To advertise WHAT? Possibly (?) it could be rewritten “... provides access, including advertising them on behalf of...”

2. Section 1

  against connection of device failure.

“Of” -> “or”

3. Section 3

  o  A route target ([RFC4360]) is attached to each GW's auto-discovery
      route and has its value set to the SR domain identifier.

Insert “(defined below)” after “auto-discovery route”, please?

  The auto-discovery route that each GW advertises consists of the
  following:

The use of the definite article implies that each GW can advertise one, and only one, auto-discovery route. Is this true?

4. Section 5

  When a packet destined for prefix X is sent on an SR TE path to a GW
  for the SR domain containing X (that is, the packet is sent in the
  Ingress Domain on an SR TE path that describes the path including
  within the Egress Domain), it needs to carry the receiving GW's label

I can’t understand the parenthetical, in particular “the path including within the Egress Domain”.

Also, do you really mean “label”, or do you mean “SID”? I don’t think you scoped this to only SR-MPLS, did you? Although reading on within §5 you talk about the “label stack”, so it does appear you’re MPLS specific — probably this should be said up front, in that case? The title should really be “… for SR-MPLS Enabled Domain Interconnection”?

5. Section 6

  If the GWs for a given SR domain are configured to allow remote GWs
  to send them a packet in that SR domain's native encapsulation, then

This is forbidden by RFC 8402, see my discuss comment #3. Maybe this is just an easy terminology fix, or maybe not.

6. Section 8

  All of the issues in the list above could cause disruption to domain
  interconnection, but are not new protocol vulnerabilities so much as
  new exposures of information that SHOULD be protected against using
  existing protocol mechanisms.  Furthermore, it is a general

What are the existing BGP protocol mechanisms that could be used to protect against exposure of information? BGP itself doesn’t have any confidentiality features nor do most of its common transports. Maybe you mean something different, but if so that’s not clear to me.

  system.  It should be noted that BGP peerings are not discovered, but
  always arise from explicit configuration.

This is true at present, but IDR has work in progress on autodiscovery. (Same comment applies with respect to Section 9.)

7. Section 9.1

  consideration.  When using the mechanisms defined in this document,
  the operator should consider carefully the effects of filtering
  routes.  In some cases this may be desirable, and in others it could
  limit the effectiveness of the procedures.

I believe the only use of route targets in this document is for the autodiscovery routes.  If RTC were in use, through its normal operation the gateways would exchange autodiscovery routes exactly as this specification needs them to. So your cryptic warning above leaves me wondering, what are the cases in which RTC impedes the function of the specification?

8. General

The autodiscovery mechanism is clear as far as it goes, but I think not all failure modes are addressed. In particular, if there’s partial connectivity within a domain, I think long-term black holing can ensue. Consider this case: GW1 and GW2 are gateways in domain A. GW3 is a gateway in domain B. GW1 and GW2 discover one another and advertise one another’s encapsulation information accordingly, when advertising a route to prefix X. However, there’s a problem within GW1 and GW2’s domain, such that GW1 can reach X, but GW2 can’t. Even though GW2 may know it can’t reach X, and indeed GW2 isn’t advertising X, GW1 is still advertising GW2 as a viable gateway to reach X, and GW3 may well route traffic for X via GW2.

Admittedly, having partial connectivity within a domain as I’ve described is a broken situation to begin with, but stuff happens, and your spec would make matters worse. It might be worth acknowledging this issue somewhere in the document?
2021-05-13
10 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2021-05-12
10 Amy Vezza Placed on agenda for telechat - 2021-05-20
2021-05-12
10 Martin Vigoureux Ballot has been issued
2021-05-12
10 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2021-05-12
10 Martin Vigoureux Created "Approve" ballot
2021-05-12
10 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2021-05-12
10 Martin Vigoureux Ballot writeup was changed
2021-05-01
10 Ravi Singh Request for Early review by RTGDIR Completed: Ready. Reviewer: Ravi Singh.
2021-04-29
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-04-28
10 Gyan Mishra Request for Last Call review by GENART Completed: Not Ready. Reviewer: Gyan Mishra. Sent review to list.
2021-04-27
10 Daniel Migault Request for Last Call review by SECDIR Completed: Ready. Reviewer: Daniel Migault. Sent review to list.
2021-04-22
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2021-04-22
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2021-04-21
10 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2021-04-21
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bess-datacenter-gateway-10. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bess-datacenter-gateway-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the BGP Tunnel Encapsulation Attribute Tunnel Types registry on the Border Gateway Protocol (BGP) Tunnel Encapsulation registry page located at:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

the following registration:

Value: 17
Description: SR Tunnel

will be marked (DEPRECATED) and its reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-04-16
10 Min Ye Request for Early review by RTGDIR is assigned to Ravi Singh
2021-04-16
10 Min Ye Request for Early review by RTGDIR is assigned to Ravi Singh
2021-04-15
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Daniel Migault
2021-04-15
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Daniel Migault
2021-04-15
10 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2021-04-15
10 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2021-04-15
10 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-04-15
10 Amy Vezza
The following Last Call announcement was sent out (ends 2021-04-29):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Matthew Bocci <matthew.bocci@nokia.com …
The following Last Call announcement was sent out (ends 2021-04-29):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Matthew Bocci <matthew.bocci@nokia.com>, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-datacenter-gateway@ietf.org, martin.vigoureux@nokia.com, matthew.bocci@nokia.com
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-bess-datacenter-gateway-10.txt> (Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Gateway Auto-Discovery and Route
Advertisement for Segment Routing
  Enabled Domain Interconnection'
  <draft-ietf-bess-datacenter-gateway-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-04-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Data centers are critical components of the infrastructure used by
  network operators to provide services to their customers.  Data
  centers are attached to the Internet or a backbone network by gateway
  routers.  One data center typically has more than one gateway for
  commercial, load balancing, and resiliency reasons.

  Segment Routing is a protocol mechanism that can be used within a
  data center, and also for steering traffic that flows between two
  data center sites.  In order that one data center site may load
  balance the traffic it sends to another data center site, it needs to
  know the complete set of gateway routers at the remote data center,
  the points of connection from those gateways to the backbone network,
  and the connectivity across the backbone network.

  Segment Routing may also be operated in other domains, such as access
  networks.  Those domains also need to be connected across backbone
  networks through gateways.

  This document defines a mechanism using the BGP Tunnel Encapsulation
  attribute to allow each gateway router to advertise the routes to the
  prefixes in the Segment Routing domains to which it provides access,
  and also to advertise on behalf of each other gateway to the same
  Segment Routing domain.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/



No IPR declarations have been submitted directly on this I-D.




2021-04-15
10 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-04-15
10 Martin Vigoureux Requested Early review by RTGDIR
2021-04-15
10 Martin Vigoureux Last call was requested
2021-04-15
10 Martin Vigoureux Ballot approval text was generated
2021-04-15
10 Martin Vigoureux Ballot writeup was generated
2021-04-15
10 (System) Changed action holders to Martin Vigoureux (IESG state changed)
2021-04-15
10 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-04-15
10 Martin Vigoureux Last call announcement was generated
2021-04-15
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-04-15
10 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-10.txt
2021-04-15
10 (System) New version accepted (logged-in submitter: Adrian Farrel)
2021-04-15
10 Adrian Farrel Uploaded new revision
2021-04-13
09 (System) Changed action holders to Adrian Farrel, Keyur Patel, John Drake, Eric Rosen, Luay Jalil (IESG state changed)
2021-04-13
09 Martin Vigoureux IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-02-09
09 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2021-01-05
09 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-09.txt
2021-01-05
09 (System) New version accepted (logged-in submitter: Adrian Farrel)
2021-01-05
09 Adrian Farrel Uploaded new revision
2020-08-13
08 Matthew Bocci
Document shepherd writeup for draft-ietf-bess-datacenter-gateway-08

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this …
Document shepherd writeup for draft-ietf-bess-datacenter-gateway-08

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests a code
point from an IANA registry for which the allocation policy is standards action.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Data centers are critical components of the infrastructure used by
  network operators to provide services to their customers.  Data
  centers are attached to the Internet or a backbone network by gateway
  routers.  One data center typically has more than one gateway for
  commercial, load balancing, and resiliency reasons.

  Segment Routing is a protocol mechanism that can be used within a
  data center, and also for steering traffic that flows between two
  data center sites.  In order that one data center site may load
  balance the traffic it sends to another data center site, it needs to
  know the complete set of gateway routers at the remote data center,
  the points of connection from those gateways to the backbone network,
  and the connectivity across the backbone network.

  Segment Routing may also be operated in other domains, such as access
  networks.  Those domains also need to be connected across backbone
  networks through gateways.

  This document defines a mechanism using the BGP Tunnel Encapsulation
  attribute to allow each gateway router to advertise the routes to the
  prefixes in the Segment Routing domains to which it provides access,
  and also to advertise on behalf of each other gateway to the same
  Segment Routing domain.

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. These services
are often deployed across datacenters and use segment routing  as the tunnel technology.
A solution was needed to allow load balancing, resiliency, etc., for such traffic when
routed between datacenters through multiple DC gateways which may reside in different
domains.

This draft provides a solution to allow the discovery of multiple DC gateway routers
in such scenarios. The document was developed over a period
of time in the BESS WG, but required an extended WG last call to ensure sufficient review,
as well as additional cross review of some points with the IDR WG.

Document Quality:

Segment routing for supporting BGP based services between data centers is becoming
widely deployed. The document is leverages relatively mature BGP extensions described
in a draft which is currently in the RFC editors queue.

The draft received a number of comments during WG last call which were addressed.

I have no concerns about the quality of the document.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

I reviewed Version 8 of the draft. I have no significant comments on the draft. It is
clear and readable.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It also received an RTG DIR review and cross-reviewed with
the IDR working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No formal reviews required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

There is solid consensus behind the daft. There were a significant number
of participants who indicated support afer the extended WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


ID nits passes.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

No formal review requirements.

(13) Have all references within this document been identified as either
normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are to published RFCs.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There is one IANA action. This is for the new SR Tunnel Sub-TLV from the BGP Tunnel
Encapsulation Attribute Sub-TLVs registry. This is properly called out in the IANA
considerations section and its usage documented in the body of the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

The document does not define any YANG modules.
2020-08-13
08 Matthew Bocci Responsible AD changed to Martin Vigoureux
2020-08-13
08 Matthew Bocci IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-08-13
08 Matthew Bocci IESG state changed to Publication Requested from I-D Exists
2020-08-13
08 Matthew Bocci IESG process started in state Publication Requested
2020-08-13
08 Matthew Bocci Tag Doc Shepherd Follow-up Underway set.
2020-08-13
08 Matthew Bocci IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2020-08-13
08 Matthew Bocci Changed consensus to Yes from Unknown
2020-08-13
08 Matthew Bocci Intended Status changed to Proposed Standard from None
2020-08-13
08 Matthew Bocci
Document shepherd writeup for draft-ietf-bess-datacenter-gateway-08

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this …
Document shepherd writeup for draft-ietf-bess-datacenter-gateway-08

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests a code
point from an IANA registry for which the allocation policy is standards action.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Data centers are critical components of the infrastructure used by
  network operators to provide services to their customers.  Data
  centers are attached to the Internet or a backbone network by gateway
  routers.  One data center typically has more than one gateway for
  commercial, load balancing, and resiliency reasons.

  Segment Routing is a protocol mechanism that can be used within a
  data center, and also for steering traffic that flows between two
  data center sites.  In order that one data center site may load
  balance the traffic it sends to another data center site, it needs to
  know the complete set of gateway routers at the remote data center,
  the points of connection from those gateways to the backbone network,
  and the connectivity across the backbone network.

  Segment Routing may also be operated in other domains, such as access
  networks.  Those domains also need to be connected across backbone
  networks through gateways.

  This document defines a mechanism using the BGP Tunnel Encapsulation
  attribute to allow each gateway router to advertise the routes to the
  prefixes in the Segment Routing domains to which it provides access,
  and also to advertise on behalf of each other gateway to the same
  Segment Routing domain.

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. These services
are often deployed across datacenters and use segment routing  as the tunnel technology.
A solution was needed to allow load balancing, resiliency, etc., for such traffic when
routed between datacenters through multiple DC gateways which may reside in different
domains.

This draft provides a solution to allow the discovery of multiple DC gateway routers
in such scenarios. The document was developed over a period
of time in the BESS WG, but required an extended WG last call to ensure sufficient review,
as well as additional cross review of some points with the IDR WG.

Document Quality:

Segment routing for supporting BGP based services between data centers is becoming
widely deployed. The document is leverages relatively mature BGP extensions described
in a draft which is currently in the RFC editors queue.

The draft received a number of comments during WG last call which were addressed.

I have no concerns about the quality of the document.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

I reviewed Version 8 of the draft. I have no significant comments on the draft. It is
clear and readable.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It also received an RTG DIR review and cross-reviewed with
the IDR working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No formal reviews required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

There is solid consensus behind the daft. There were a significant number
of participants who indicated support afer the extended WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


ID nits passes.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

No formal review requirements.

(13) Have all references within this document been identified as either
normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are to published RFCs.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There is one IANA action. This is for the new SR Tunnel Sub-TLV from the BGP Tunnel
Encapsulation Attribute Sub-TLVs registry. This is properly called out in the IANA
considerations section and its usage documented in the body of the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

The document does not define any YANG modules.
2020-08-12
08 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-08.txt
2020-08-12
08 (System) New version accepted (logged-in submitter: Adrian Farrel)
2020-08-12
08 Adrian Farrel Uploaded new revision
2020-06-30
07 Min Ye Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Ravi Singh.
2020-06-04
07 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-07.txt
2020-06-04
07 (System) New version accepted (logged-in submitter: Adrian Farrel)
2020-06-04
07 Adrian Farrel Uploaded new revision
2020-06-02
06 Min Ye Request for Early review by RTGDIR is assigned to Ravi Singh
2020-06-02
06 Min Ye Request for Early review by RTGDIR is assigned to Ravi Singh
2020-06-02
06 Matthew Bocci Requested Early review by RTGDIR
2020-06-02
06 Matthew Bocci Notification list changed to Matthew Bocci <matthew.bocci@nokia.com>
2020-06-02
06 Matthew Bocci Document shepherd changed to Matthew Bocci
2020-06-01
06 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-06.txt
2020-06-01
06 (System) New version accepted (logged-in submitter: Adrian Farrel)
2020-06-01
06 Adrian Farrel Uploaded new revision
2020-03-11
05 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-05.txt
2020-03-11
05 (System) New version approved
2020-03-11
05 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Luay Jalil <luay.jalil@verizon.com>, Adrian Farrel <adrian@olddog.co.uk>, Keyur Patel …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Luay Jalil <luay.jalil@verizon.com>, Adrian Farrel <adrian@olddog.co.uk>, Keyur Patel <keyur@arrcus.com>, Eric Rosen <erosen52@gmail.com>
2020-03-11
05 Adrian Farrel Uploaded new revision
2020-02-22
04 (System) Document has expired
2019-08-21
04 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-04.txt
2019-08-21
04 (System) New version approved
2019-08-21
04 (System)
Request for posting confirmation emailed to previous authors: Adrian Farrel <adrian@olddog.co.uk>, John Drake <jdrake@juniper.net>, Luay Jalil <luay.jalil@verizon.com>, Eric Rosen …
Request for posting confirmation emailed to previous authors: Adrian Farrel <adrian@olddog.co.uk>, John Drake <jdrake@juniper.net>, Luay Jalil <luay.jalil@verizon.com>, Eric Rosen <erosen52@gmail.com>, Keyur Patel <keyur@arrcus.com>
2019-08-21
04 Adrian Farrel Uploaded new revision
2019-08-20
03 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-03.txt
2019-08-20
03 (System) New version approved
2019-08-20
03 (System)
Request for posting confirmation emailed to previous authors: Adrian Farrel <adrian@olddog.co.uk>, John Drake <jdrake@juniper.net>, Luay Jalil <luay.jalil@verizon.com>, Eric Rosen …
Request for posting confirmation emailed to previous authors: Adrian Farrel <adrian@olddog.co.uk>, John Drake <jdrake@juniper.net>, Luay Jalil <luay.jalil@verizon.com>, Eric Rosen <erosen52@gmail.com>, Keyur Patel <keyur@arrcus.com>
2019-08-20
03 Adrian Farrel Uploaded new revision
2019-02-26
02 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-02.txt
2019-02-26
02 (System) New version approved
2019-02-26
02 (System)
Request for posting confirmation emailed to previous authors: Luay Jalil <luay.jalil@verizon.com>, John Drake <jdrake@juniper.net>, Adrian Farrel <afarrel@juniper.net>, Eric Rosen …
Request for posting confirmation emailed to previous authors: Luay Jalil <luay.jalil@verizon.com>, John Drake <jdrake@juniper.net>, Adrian Farrel <afarrel@juniper.net>, Eric Rosen <erosen@juniper.net>, Keyur Patel <keyur@arrcus.com>, bess-chairs@ietf.org
2019-02-26
02 Adrian Farrel Uploaded new revision
2018-11-05
01 (System) Document has expired
2018-05-02
01 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-01.txt
2018-05-02
01 (System) New version approved
2018-05-02
01 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Keyur Patel <keyur@arrcus.com>, Adrian Farrel <afarrel@juniper.net>, Eric Rosen …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Keyur Patel <keyur@arrcus.com>, Adrian Farrel <afarrel@juniper.net>, Eric Rosen <erosen@juniper.net>, Luay Jalil <luay.jalil@verizon.com>
2018-05-02
01 Adrian Farrel Uploaded new revision
2018-04-30
00 (System) Document has expired
2017-10-30
00 Thomas Morin This document now replaces draft-drake-bess-datacenter-gateway instead of None
2017-10-27
00 Adrian Farrel New version available: draft-ietf-bess-datacenter-gateway-00.txt
2017-10-27
00 (System) WG -00 approved
2017-10-27
00 Adrian Farrel Set submitter to "Adrian Farrel <afarrel@juniper.net>", replaces to (none) and sent approval email to group chairs: bess-chairs@ietf.org
2017-10-27
00 Adrian Farrel Uploaded new revision