Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Gyan Mishra]

Dear Authors,

Attached is a txt version -gsm update of version 10 that contains a first
cut at what I think would be appropriate  RFC 2119 SHOULD / MUST
language for a specification.  I also made some editorial updates to make
the specification clear to the reader.  In this thread and on the call we
had we talked about changing the ingress & egress domain to ingress &
egress site which I made that change as well.  Using the word "domain"
really makes it confusing as
to which domain is being referred  so the change to "site" really helps
readability.

Few more questions & thoughts  related to the draft for the authors to help
in finalizing the draft for publication below:

GW failover: (John Scudder)
GW's will need a local iBGP session for failover.  In the scenario where
one GW is disconnected from the backbone the draft clearly states that the
advertisement of the GW is withdrawn, when the active set of GWs changes
each externally advertised route will be re-advertised with the new tunnel
encapsulation attribute union which reflects the current set of active
GWs.
In the case of inconsistent routing within the site GW1 can reach GW2, GW1
cannot reach S2. Low probability but entirely possible.  Maybe a note in
the draft on this scenario may make things worse with blackhole to GW2.

Section 5 - RFC 9012 Tunnel encapsulation attribute BGP Prefix-sid
limitations (Alvaro Retana)
SR end to end or at a minimum within an SR domain may not be general use
case and maybe limited due to BGP prefix sid sub-tlv can only be used for
IPv4/IPv6 labeled unicast AFI/SAFI 1/4 2/4.
We may want to comment in section 5 that use of SR maybe limited and not a
general use case.  Also does this limitation impact the use of SRv6?

Additional thoughts for the authors.

Does the draft require SR in the backbone or can RSVP-TE be used?

If RSVP-TE can be used, maybe a different name for the identifier should be
used and not SR domain identifier.

Section 3 - Is the SR domain identifier value the RT that is attached to
the GW auto discovery route?

RFC 4360 is mentioned in section 3 as normative reference, however RFC 5668
4 byte extended community should also be mentioned as normative.

We may want to mention this bleed over of GW routes due to
mis-configuration in section 8 - security considerations

   Note that if a GW is (mis)configured with a different SR domain

   identifier from the other GWs to the same domain 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.

As there may be significant propagation delays with convergence for
re-advertisement as the set of active GWs change in cases where the number
of AS's is very large over the public internet, maybe that should be
mentioned.

Kind Regards

Gyan



On Tue, May 18, 2021 at 4:49 PM John E Drake  wrote:

> Excellent, thanks so much for your help on this.
>
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
>
> > -Original Message-
> > From: Gyan Mishra 
> > Sent: Tuesday, May 18, 2021 4:28 PM
> > To: Lars Eggert 
> > Cc: General Area Review Team ; bess@ietf.org;
> draft-ietf-
> > bess-datacenter-gateway@ietf.org; last-c...@ietf.org
> > Subject: Re: [Last-Call] Genart last call review of
> draft-ietf-bess-datacenter-
> > gateway-10
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Lars’s  & DC Gateway authors
> >
> > I will be responding back today to the Gen-Art original email I sent
> with final
> > comments and hope the final comments will help improve the document.
> >
> > I will also address the comments from John Scudder related to GW
> failover as
> > well as Alvaro’s comments related to tunnel encapsulation attribute BGP
> prefix
> > sid Sub-TLV limitations.  Also will add new text recommendations related
> to RFC
> > 2119 MUST / SHOULD language to help improve the document.
> >
> >
> > Thank you
> >
> > Gyan
> > On Tue, May 18, 2021 at 3:31 AM Lars Eggert  wrote:
> >
> > > Gyan, thank you for your review and thank you all for the following
> > > discussion. I have entered a No Objection ballot for this document
> > > based on the current status of the discussion.
> > >
> > > Lars
> > >
> > >
> > > > On 2021-4-29, at 8:46, Gyan Mishra via Datatracker
> > > > 
> > > wrote:
> > > >
> > > > Reviewer: Gyan Mishra
> > > > Review result: Not Ready
> > > >
> > > > I am the assigned Gen-ART reviewer for this draft. The General Area
> > > > Review Team (Gen-ART) reviews all IETF documents being processed by
> > > > the IESG for the IETF Chair.  Please treat these comments just like
> > > > any other last call comments.
> > > >
> > > > For more information, please see the FAQ at
> > > >
> > > >
> > <
> https://urldefense.com/v3/__https://trac.ietf.org/trac/

[bess] Warren Kumari's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


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



--
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.





___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Adrian Farrel]

Thanks Alvaro,

> 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).

This ties into other comments on the thread: we should have used the term 
"site" not "domain" as the meaning of "SR domain" is already nailed down in 
8402.
An almost global change of "domain" to "site" will be made in -11.
While this doesn't change the casualness or otherwise of the document, it does 
prevent any changes to the SR architecture.

Cheers,
Adrian

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[John E Drake]

Excellent, thanks so much for your help on this.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Gyan Mishra 
> Sent: Tuesday, May 18, 2021 4:28 PM
> To: Lars Eggert 
> Cc: General Area Review Team ; bess@ietf.org; draft-ietf-
> bess-datacenter-gateway@ietf.org; last-c...@ietf.org
> Subject: Re: [Last-Call] Genart last call review of 
> draft-ietf-bess-datacenter-
> gateway-10
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Lars’s  & DC Gateway authors
> 
> I will be responding back today to the Gen-Art original email I sent with 
> final
> comments and hope the final comments will help improve the document.
> 
> I will also address the comments from John Scudder related to GW failover 
> as
> well as Alvaro’s comments related to tunnel encapsulation attribute BGP prefix
> sid Sub-TLV limitations.  Also will add new text recommendations related to 
> RFC
> 2119 MUST / SHOULD language to help improve the document.
> 
> 
> Thank you
> 
> Gyan
> On Tue, May 18, 2021 at 3:31 AM Lars Eggert  wrote:
> 
> > Gyan, thank you for your review and thank you all for the following
> > discussion. I have entered a No Objection ballot for this document
> > based on the current status of the discussion.
> >
> > Lars
> >
> >
> > > On 2021-4-29, at 8:46, Gyan Mishra via Datatracker
> > > 
> > wrote:
> > >
> > > Reviewer: Gyan Mishra
> > > Review result: Not Ready
> > >
> > > I am the assigned Gen-ART reviewer for this draft. The General Area
> > > Review Team (Gen-ART) reviews all IETF documents being processed by
> > > the IESG for the IETF Chair.  Please treat these comments just like
> > > any other last call comments.
> > >
> > > For more information, please see the FAQ at
> > >
> > >
>  !!NEt6yMaO-gk!RIcJvmiBoFFiuLezPbzRuUXybG_QHD8PujD7pROBUPot5dc9nX-
> rMTiD1THCYZA$ >.
> > >
> > > Document: draft-ietf-bess-datacenter-gateway-??
> > > Reviewer: Gyan Mishra
> > > Review Date: 2021-04-28
> > > IETF LC End Date: 2021-04-29
> > > IESG Telechat date: Not scheduled for a telechat
> > >
> > > Summary:
> > >   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.
> > >
> > > This draft needs to provide some more clarity as far as the use case
> > > and
> > where
> > > this would as well as how it would be used and implemented.  From
> > reading the
> > > specification it appears there are some technical gaps that exist.
> > > There
> > are
> > > some major issues with this draft. I don’t think this draft is ready yet.
> > >
> > > Major issues:
> > >
> > > Abstract comments:
> > > It is mentioned that the use of Segment Routing within the Data Center.
> > Is
> > > that a requirement for this specification to work as this is
> > > mentioned throughout the draft?  Technically I would think the
> > > concept of the
> > discovery
> > > of the gateways is feasible without the requirement of SR within the
> > > Data Center.
> > >
> > > The concept of load balancing is a bigger issue brought up in this
> > > draft
> > as the
> > > problem statement and what this draft is trying to solve which I
> > > will
> > address
> > > in the introduction comments.
> > >
> > > Introduction comments:
> > > In the introduction the use case is expanded much further to any
> > functional
> > > edge AS verbiage below.
> > >
> > > OLD
> > >
> > >   “SR may also be operated in other domains, such as access networks.
> > >   Those domains also need to be connected across backbone networks
> > >   through gateways.  For illustrative purposes, consider the Ingress
> > >   and Egress SR Domains shown in Figure 1 as separate ASes.  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”
> > >
> > > This paragraph expands the use case to any ingress or egress stub
> > > domain
> > Data
> > > Center, Access or any.  If that is the case should the draft name
> > > change
> > to
> > > maybe a “stub edge domain services discovery”.  As this draft can be
> > used for
> > > any I would not preclude any use case and make the GW discovery open
> > > to
> > be used
> > > for any service GW edge function and change the draft name to
> > > something
> > more
> > > appropriate.
> > >
> > > This paragraph also states for illustrative purposes which is fine
> > > but
> > then it
> > > expands the overlay/underlay use cases. I believe this use case can
> > > only
> > be
> > > used for any technology that has an overlay/underlay wh

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Gyan Mishra]

Hi Lars’s  & DC Gateway authors

I will be responding back today to the Gen-Art original email I sent with
final comments and hope the final comments will help improve the document.

I will also address the comments from John Scudder related to GW
failover as well as Alvaro’s comments related to tunnel encapsulation
attribute BGP prefix sid Sub-TLV limitations.  Also will add new text
recommendations related to RFC 2119 MUST / SHOULD language to help improve
the document.


Thank you

Gyan
On Tue, May 18, 2021 at 3:31 AM Lars Eggert  wrote:

> Gyan, thank you for your review and thank you all for the following
> discussion. I have entered a No Objection ballot for this document based on
> the current status of the discussion.
>
> Lars
>
>
> > On 2021-4-29, at 8:46, Gyan Mishra via Datatracker 
> wrote:
> >
> > Reviewer: Gyan Mishra
> > Review result: Not Ready
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
> > like any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > .
> >
> > Document: draft-ietf-bess-datacenter-gateway-??
> > Reviewer: Gyan Mishra
> > Review Date: 2021-04-28
> > IETF LC End Date: 2021-04-29
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >   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.
> >
> > This draft needs to provide some more clarity as far as the use case and
> where
> > this would as well as how it would be used and implemented.  From
> reading the
> > specification it appears there are some technical gaps that exist. There
> are
> > some major issues with this draft. I don’t think this draft is ready yet.
> >
> > Major issues:
> >
> > Abstract comments:
> > It is mentioned that the use of Segment Routing within the Data Center.
> Is
> > that a requirement for this specification to work as this is mentioned
> > throughout the draft?  Technically I would think the concept of the
> discovery
> > of the gateways is feasible without the requirement of SR within the Data
> > Center.
> >
> > The concept of load balancing is a bigger issue brought up in this draft
> as the
> > problem statement and what this draft is trying to solve which I will
> address
> > in the introduction comments.
> >
> > Introduction comments:
> > In the introduction the use case is expanded much further to any
> functional
> > edge AS verbiage below.
> >
> > OLD
> >
> >   “SR may also be operated in other domains, such as access networks.
> >   Those domains also need to be connected across backbone networks
> >   through gateways.  For illustrative purposes, consider the Ingress
> >   and Egress SR Domains shown in Figure 1 as separate ASes.  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”
> >
> > This paragraph expands the use case to any ingress or egress stub domain
> Data
> > Center, Access or any.  If that is the case should the draft name change
> to
> > maybe a “stub edge domain services discovery”.  As this draft can be
> used for
> > any I would not preclude any use case and make the GW discovery open to
> be used
> > for any service GW edge function and change the draft name to something
> more
> > appropriate.
> >
> > This paragraph also states for illustrative purposes which is fine but
> then it
> > expands the overlay/underlay use cases. I believe this use case can only
> be
> > used for any technology that has an overlay/underlay which would
> preclude any
> > use case with just an underlay global table routing such as what is
> mentioned
> > “IP, MPLS with global table routing native BGP to the edge.  The IP or
> global
> > table routing would be an issue as this specification requires setting a
> RT and
> > an export/import RT policy for the discover of routes advertised by the
> GWs.
> > As I don’t think this solution from what I can tell would work
> technically for
> > global table routing I will update the above paragraph to preclude
> global table
> > routing.  We can add back in we can figure that out but I don’t think any
> > public or private operator would change from global table carrying all
> BGP
> > prefixes in the underlay now drastic change to VPN overlay pushing all
> the
> > any-any prefixes into the overlay as that would be a prerequisite to be
> able to
> > use this draft.
> >
> >> From this po

Re: [bess] SRv6 / (SR)MPLS co-existence for bess

[Eduard Metz]

Thanks!
I overlooked that this draft already has a placeholder for co-existence, no
specific approaches included yet.
Would be happy to contribute if needed.

cheers,
  Eduard

On Tue, May 18, 2021 at 2:13 PM Ketan Talaulikar (ketant) 
wrote:

> Hi Eduard,
>
>
>
> I do believe that BGP ADD-PATH mechanism can be leveraged for
> co-existence. There are also other design approaches to achieve the same.
>
>
>
> I am copying the authors of
> https://datatracker.ietf.org/doc/draft-agrawal-spring-srv6-mpls-interworking/
> who were working to document these approaches.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* BESS  *On Behalf Of *Eduard Metz
> *Sent:* 17 May 2021 13:46
> *To:* bess@ietf.org
> *Subject:* [bess] SRv6 / (SR)MPLS co-existence for bess
>
>
>
> Hello,
>
>
>
> Co-existence of multiple dataplane technologies to carry BESS services is
> useful for among others migration of one dataplane technology to another
> (e.g. (SR)MPLS to SRv6).
>
>
>
> Can co-existence be achieved without changing current specifications, or
> would it require extensions / changes? For example as proposed in
> draft-ls-bess-srv6-mpls-coexisting-vpn.
>
>
>
> I was thinking maybe the BGP ADD-PATH capability could be leveraged to
> achieve co-existence.
>
>
>
> Would it be of interest to document co-existence cases and solutions?
>
>
>
> Thanks!
>
>
>
> cheers,
>
>   Eduard
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] SRv6 / (SR)MPLS co-existence for bess

[Ketan Talaulikar (ketant)]

Hi Eduard,

I do believe that BGP ADD-PATH mechanism can be leveraged for co-existence. 
There are also other design approaches to achieve the same.

I am copying the authors of 
https://datatracker.ietf.org/doc/draft-agrawal-spring-srv6-mpls-interworking/ 
who were working to document these approaches.

Thanks,
Ketan

From: BESS  On Behalf Of Eduard Metz
Sent: 17 May 2021 13:46
To: bess@ietf.org
Subject: [bess] SRv6 / (SR)MPLS co-existence for bess

Hello,

Co-existence of multiple dataplane technologies to carry BESS services is 
useful for among others migration of one dataplane technology to another (e.g. 
(SR)MPLS to SRv6).

Can co-existence be achieved without changing current specifications, or would 
it require extensions / changes? For example as proposed in 
draft-ls-bess-srv6-mpls-coexisting-vpn.

I was thinking maybe the BGP ADD-PATH capability could be leveraged to achieve 
co-existence.

Would it be of interest to document co-existence cases and solutions?

Thanks!

cheers,
  Eduard
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Adrian Farrel]

Hi Erik,

Yes, per other discussions resulting from IESG review and Directorate reviews, 
we need to clarify our use of the word "domain".

The context of an "SR domain" in RFC 8402 is "all nodes participating in an SR 
system" and that is assumed to include nodes that are not physically adjacent 
but which have tunnels between them, even including regular IP forwarding 
without inspection of the SRH (the IP nodes are not in the domain, but the 
segment end points are).

Our use of "domain" was broken in this view of the world and we are fixing it.
We will use the word "site" to describe the end locations (such as DCs) in a 
way that models the naming for VPNs.

In an 8402 context, all interconnected sites are part of the same SR domain.

Thus, I think, the question of filtering at the domain boundary is unchanged.

Thanks,
Adrian
-Original Message-
From: Erik Kline via Datatracker  
Sent: 18 May 2021 07:24
To: The IESG 
Cc: draft-ietf-bess-datacenter-gate...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Matthew Bocci ; matthew.bo...@nokia.com
Subject: Erik Kline's No Objection on draft-ietf-bess-datacenter-gateway-10: 
(with COMMENT)

Erik Kline has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


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



--
COMMENT:
--

[[ 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.



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Lars Eggert]

Gyan, thank you for your review and thank you all for the following discussion. 
I have entered a No Objection ballot for this document based on the current 
status of the discussion.

Lars


> On 2021-4-29, at 8:46, Gyan Mishra via Datatracker  wrote:
> 
> Reviewer: Gyan Mishra
> Review result: Not Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-bess-datacenter-gateway-??
> Reviewer: Gyan Mishra
> Review Date: 2021-04-28
> IETF LC End Date: 2021-04-29
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
>   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.
> 
> This draft needs to provide some more clarity as far as the use case and where
> this would as well as how it would be used and implemented.  From reading the
> specification it appears there are some technical gaps that exist. There are
> some major issues with this draft. I don’t think this draft is ready yet.
> 
> Major issues:
> 
> Abstract comments:
> It is mentioned that the use of Segment Routing within the Data Center.  Is
> that a requirement for this specification to work as this is mentioned
> throughout the draft?  Technically I would think the concept of the discovery
> of the gateways is feasible without the requirement of SR within the Data
> Center.
> 
> The concept of load balancing is a bigger issue brought up in this draft as 
> the
> problem statement and what this draft is trying to solve which I will address
> in the introduction comments.
> 
> Introduction comments:
> In the introduction the use case is expanded much further to any functional
> edge AS verbiage below.
> 
> OLD
> 
>   “SR may also be operated in other domains, such as access networks.
>   Those domains also need to be connected across backbone networks
>   through gateways.  For illustrative purposes, consider the Ingress
>   and Egress SR Domains shown in Figure 1 as separate ASes.  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”
> 
> This paragraph expands the use case to any ingress or egress stub domain Data
> Center, Access or any.  If that is the case should the draft name change to
> maybe a “stub edge domain services discovery”.  As this draft can be used for
> any I would not preclude any use case and make the GW discovery open to be 
> used
> for any service GW edge function and change the draft name to something more
> appropriate.
> 
> This paragraph also states for illustrative purposes which is fine but then it
> expands the overlay/underlay use cases. I believe this use case can only be
> used for any technology that has an overlay/underlay which would preclude any
> use case with just an underlay global table routing such as what is mentioned
> “IP, MPLS with global table routing native BGP to the edge.  The IP or global
> table routing would be an issue as this specification requires setting a RT 
> and
> an export/import RT policy for the discover of routes advertised by the GWs.
> As I don’t think this solution from what I can tell would work technically for
> global table routing I will update the above paragraph to preclude global 
> table
> routing.  We can add back in we can figure that out but I don’t think any
> public or private operator would change from global table carrying all BGP
> prefixes in the underlay now drastic change to VPN overlay pushing all the
> any-any prefixes into the overlay as that would be a prerequisite to be able 
> to
> use this draft.
> 
>> From this point forward I am going to assume we are using VPN overlay
> technology such as SR or MPLS.
> 
> NEW
> 
>   “SR may also be operated in other domains, such as access networks.
>   Those domains also need to be connected across backbone networks
>   through gateways.  For illustrative purposes, consider the Ingress
>   and Egress SR Domains shown in Figure 1 as separate ASes.  The
>   various ASs that provide connectivity between the Ingress and Egress
>   Domains could be two as shown in Figure-1 or could be many more as exists
>   with the public internet use case, and each may be constructed differently
>   and use different technologies such as MPLS IP VPN, SR-MPLS IP VPN, or SRv6
>   IP VPN” with a “BGP Free” Core.
> 
> This may work