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 |