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

[Eduard Metz]

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] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Lars Eggert]

Gyan, thank you for your review. I have not seen a response from the editors to 
your review yet, and so I'm holding off for the moment on entering a ballot for 
this document.

Authors, would you please respond to Gyan's review?

Thanks,
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
>

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

[Gyan Mishra]

Hi Lars

I met with the authors on Friday 5/14 and we went over my questions and
review of the draft in detail.

I will respond today with a detailed update on the status of my review
based on feedback from the authors from Friday meeting that the draft is in
a “Ready” state with minor updates & recommendations.

Kind Regards

Gyan

On Mon, May 17, 2021 at 4:38 AM Lars Eggert  wrote:

> Gyan, thank you for your review. I have not seen a response from the
> editors to your review yet, and so I'm holding off for the moment on
> entering a ballot for this document.
>
> Authors, would you please respond to Gyan's review?
>
> Thanks,
> 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

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

[Éric Vyncke via Datatracker]

Éric Vyncke 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:
--

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)" ?



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

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

[Adrian Farrel]

Hi Eric,

| Thank you for the work put into this document.
|
| I support John Scudder's first DISCUSS point.

Fair enough.

What did you think of my response to John

>> DISCUSS:
>>
>> 1. There’s surprisingly little in this document that seems to be SR-specific
>> (and what there is, has some problems, see below). Is there some reason you
>> rule out interconnecting domains using other tunneling technologies? I ask 
>> this
>> question first because if the answer were to be “oh huh, we don’t need to 
>> make
>> this SR-specific after all” some of the other things I’m asking about might 
>> go
>> away.
>
> I'm sorry this isn't clear, but the use of other tunnelling technologies is 
> very much
> in scope. As the Introduction says:
>
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.
>
> SR is used to identify the tunnels and provide end-to-end SR paths because the
> ingress and egress domains are SR domains, and the objective is to provide an
> end-to-end SR path.
>
> So we are not "making this SR aware" so much as enabling "SR-over-foo" using
> SIDs to identify the path segments that are tunnels.
>
> I don't know how to make this clearer except maybe using some red paint. We
> would write...
>
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.  That is, the
>   Ingress and Egress SR Domains can be connected by tunnels across a
>   variety of technologies.  This document describes how SR identifiers
>   (SIDs) are used to identify the paths between the Ingress and Egress
>   and the techniques in this document apply to routes of all AFI/SAFIs.


| Please find below some non-blocking COMMENT points (but replies
| would be appreciated), and some nits.
|
| == COMMENTS ==
|
| -- Section 3 --
| How will the GW identifiers be unique across all interconnected SR domains ?
| Section 9 is rather hand waving.

There are two issues to be resolved:
1. How will all interconnected SR sites (formerly called domains) use different 
site identifiers?
2. How will all gateways to the same site consistently use the same identifier?

Just like the mechanisms used to assign many other things in networking (IP 
addresses, AS numbers, VPN IDs, ...) there may be many approaches available 
(dedicated protocols, piggy-backing on other protocols, management protocols, 
manual configuration).

Not sure why this spec needs to be responsible for defining those 
distribution/configuration/coordination mechanisms.

Section 9 makes it very clear what result must be achieved, and observes that 
we are not introducing a new problem to the BGP world.

Could we make it clearer that the operator is responsible for getting this 
right?

| -- Section 10 --
| Is there any reason why the doc shepherd is not acknowledged ?

Of course, we love our shepherd. 
Matthew, as WG chair, pushed the right people to do reviews, and also pushed 
the right buttons to advance the document.
As shepherd, Matthew wrote: I reviewed Version 8 of the draft. I have no 
significant comments on the draft. 

The Acknowledgements section historically thanks people whose comments have 
helped shape or improve the contents of the document.

| == NITS ==
|
| -- Section 1 --
| s/against connection of device failure/against connection or device failure/ ?

Ack

| I find the use of "ingress" in "source (ingress)" confusing, should the reader
| assume that it is "source (SR-domain ingress)" ?

Could write "source DC (also known as an ingress DC)"
Ditto destination/egress

Cheers,
Adrian


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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Adrian

I am wrapping up the Gen-ART review update.

The normative draft helped tremendously in understanding the problem and
solution.  Please add to the beginning of the introduction in your next
update.

https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-05#section-9

I have a question related to the partitioning scenario.

Comments in-line

On Sun, May 16, 2021 at 7:25 AM Adrian Farrel  wrote:

> Hi John,
>
>
>
> Trying to dismantle this…
>
>
>
> We are saying that a site is integral. You are is asking : what happens if
> a site becomes partitioned so that some prefixes are accessible through one
> GW and some through another.
>
>
>
> Consider a site with a set of prefixes S
>
> Consider two GWs: GW1 and GW2
>
> Initially GW1 and GW2 discover each other.
>
> So GW1 advertises reachability to S, and by the way GW2 exists
>
> GW2 advertises reachability to S, and by the way GW1 exists
>

Gyan> Ack

> Now the site becomes partitioned so that GW1 can reach S1 and GW2 can
> reach S2. (S = S1 U S2,  S1 n S2 = E)
>
>  Gyan> Ack
>
> You ask:
>
>1. What happens to packets for S2 arriving at GW1?
>2. What is the remedy in the protocol?
>
>
>
> My answer to 1. is that the packets will be black-holed either at GW1 or
> inside the site.
>
> My observation is that:
>
>1. GW1 cannot reach GW2 inside the site. If it could, then S2 would be
>reachable via GW1
>2. It is contrary to BCP38 for GW1 to forward a packet back into the
>external AS to be routed to GW2
>
>  Gyan> How would “b” be possible as loop avoidance would drop the packet
> sent from GW1 external to loop back in GW2 being part of the same AS would
> drop the packets so they would not be able to re-discover each other via
> external.
>
> My answer to 2. is that when the site becomes partitioned:
>
>- GW1 will stop advertising the whole of S and will fall back to
>advertising just S1
>- GW2 will stop advertising the whole of S and will fall back to
>advertising just S2
>- Initially, GW1 and GW2 will still advertise each other’s existence,
>but will “soon” un-auto-discover each other
>
>
>-
>
> At this point the site is effectively two sites that use the same site
> identifier.
>
>  Gyan> Ack
>
> How quickly this takes place depends on precisely what the failure case
> is, how fast the failure detection is done, and how fast BGP converges.
>
>  Gyan> Ack
>


**Perhaps** there is a wrinkle **if** the autodetection advertisements are
> sent external to the site. In this case, GW1 would continue to discover GW2
> and so would readvertise it (and vice versa).
>
Gyan> As I stated above  “b” would not be possible so the continuing
rediscovery would not occur and GW1 and GW2 would as you stated effectively
act as two sites.

This would continue to lead to the broken condition you noted.
>

Gyan> As stated due to as-path loop avoidance the broken condition would
not occur.

I think we assumed that the peering between GW1 and GW2 would be internal
> to the site (because otherwise it would constitute traffic leaving the site
> and re-entering it (breaking BCP38 again). If it would help, we could make
> this point clear by saying that the peering between GW1 and GW2 must be
> within the site.
>
Gyan>I agree we should add explicit verbiage that iBGP per BCP38 to prevent
site partitioning as well as required for both GW1 and GW2 to be part of
the same AS and be able to provide failover and back each other Up in case
of a failure.

Gyan> I believe John mentioned this slightly different scenario but it got
lost in the thread and I tried to answer early on but I  would like to get
your take on the behavior.  As this is critical component to complete my
Gen-Art review.

So if GW2 connection to external was down but GW1 still has its connection
to external.  GW2 would auto discover GW1 over iBGP and GW2 would advertise
both GW1 and GW2 as reachable gateways.  However GW2 has its external peer
down.  So if GW1 continues to advertised GW2 as we stated GW1 will auto
discover  GW2 over iBGP.

So now for any sites trying to reach the Data Center AS that GW1 and GW2
are part of using GW2 to get to S1 and S2 would be black hole.  How do we
remedy this situation.

>
> Cheers,
>
> Adrian
>
>
>
> *From:* John Scudder 
> *Sent:* 14 May 2021 22:25
> *To:* Adrian Farrel 
> *Cc:* The IESG ;
> draft-ietf-bess-datacenter-gate...@ietf.org; bess-cha...@ietf.org;
> bess@ietf.org; Matthew Bocci 
> *Subject:* Re: John Scudder's Discuss on
> draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)
>
>
>
> Having re-read Section 3 carefully (and skimmed the rest) I still think
> what the document says (as opposed to what’s in the authors’ heads?) is the
> first description I give below. Let me know if you want me to walk through
> my reasoning in detail with reference to the document.
>
>
>
> —John
>
>
>
> On May 14, 2021, at 4:12 PM, John Scudder  wrote:
>
>  Hi Adrian,
>
>
>
> Thanks for your reply. Pr

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[John Scudder]

Hi Adrian,

Comments in line.

> On May 16, 2021, at 7:25 AM, Adrian Farrel  wrote:
> 
> 
> Hi John,
>  
> Trying to dismantle this…
>  
> We are saying that a site is integral.

I don’t think I saw any place in the draft that states that assumption.

> You are is asking : what happens if a site becomes partitioned so that some 
> prefixes are accessible through one GW and some through another.

Actually that wasn’t my scenario, I see I must have expressed it poorly. I’ll 
come back to that, but first, your own scenario.
 
> Consider a site with a set of prefixes S
> Consider two GWs: GW1 and GW2
> Initially GW1 and GW2 discover each other.
> So GW1 advertises reachability to S, and by the way GW2 exists
> GW2 advertises reachability to S, and by the way GW1 exists
> Now the site becomes partitioned so that GW1 can reach S1 and GW2 can reach 
> S2. (S = S1 U S2,  S1 n S2 = E)
>  
> You ask:
>   • What happens to packets for S2 arriving at GW1?
>   • What is the remedy in the protocol?
>  
> My answer to 1. is that the packets will be black-holed either at GW1 or 
> inside the site.
> My observation is that:
>   • GW1 cannot reach GW2 inside the site. If it could, then S2 would be 
> reachable via GW1
>   • It is contrary to BCP38 for GW1 to forward a packet back into the 
> external AS to be routed to GW2
>  
> My answer to 2. is that when the site becomes partitioned:
>   • GW1 will stop advertising the whole of S and will fall back to 
> advertising just S1
>   • GW2 will stop advertising the whole of S and will fall back to 
> advertising just S2

This, too, is unstated in the draft, and it’s not like it will happen for free 
by natural operation of every router. But in the scenario you’ve picked that 
seems OK since this practice is needed for a multi homed site regardless of 
whether your draft is in use or not — if the site partitions, either you 
deaggregate, or you black hole. (“Deaggregate” might be actual deaggregation, 
or simply advertising only the subset of individual prefixes that remain 
reachable, depending on the address allocation scheme in use, of course.)

>   • Initially, GW1 and GW2 will still advertise each other’s existence, 
> but will “soon” un-auto-discover each other
> At this point the site is effectively two sites that use the same site 
> identifier.
>  
> How quickly this takes place depends on precisely what the failure case is, 
> how fast the failure detection is done, and how fast BGP converges.  
>  
> *Perhaps* there is a wrinkle *if* the autodetection advertisements are sent 
> external to the site. In this case, GW1 would continue to discover GW2 and so 
> would readvertise it (and vice versa). This would continue to lead to the 
> broken condition you noted. I think we assumed that the peering between GW1 
> and GW2 would be internal to the site (because otherwise it would constitute 
> traffic leaving the site and re-entering it (breaking BCP38 again). If it 
> would help, we could make this point clear by saying that the peering between 
> GW1 and GW2 must be within the site.

Seems reasonable. However, it wasn’t the problem I was posing. Since that seems 
to have gotten lost in the quote-and-snip chain, here it is again:

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

The key difference between the question you answered, and the one I asked, is 
that you answer what happens in the case of a complete partition, and I ask 
what happens in the case of inconsistent routing within the site. When you 
worked through your scenario, you included this:

>   • GW1 cannot reach GW2 inside the site. If it could, then S2 would be 
> reachable via GW1

That isn’t the case in my scenario. GW1 can reach GW2, GW1 cannot reach S2. I 
think the assumption you stated up top (“the site is integral”) answers this 
question too: this case isn’t covered since it violates the assumption. I think 
that’s OK, it’s a case I’d call silly if I hadn’t seen it happen, but it’s 
still low-probability. The question was only, is it worth stating the 
assumption and what is/isn’t covered?

"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 th

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[John Scudder]

Hi Gyan, 

> On May 17, 2021, at 1:50 PM, Gyan Mishra  wrote:
> 
> So if GW2 connection to external was down but GW1 still has its connection to 
> external.  GW2 would auto discover GW1 over iBGP and GW2 would advertise both 
> GW1 and GW2 as reachable gateways.  However GW2 has its external peer down.  
> So if GW1 continues to advertised GW2 as we stated GW1 will auto discover  
> GW2 over iBGP.  

Isn’t this scenario covered? From §3:

   If a gateway becomes disconnected from the backbone network, or if
   the SR domain operator decides to terminate the gateway's activity,
   it withdraws the advertisements described above.  This means that
   remote gateways at other sites will stop seeing advertisements from
   this gateway.

So when GW2’s external peering goes down, GW2 withdraws its auto discovery 
route, and therefore GW1 re-advertises its routes externally without GW2 listed 
in the tunnel attribute.

I will say that reviewing the above-quoted text — which seems tailor-made for a 
“MUST withdraw” — made me notice that the draft makes only sporadic and 
desultory use of RFC2119 keywords. In fact there are so few used, that it seems 
like it might be better to scrub those two SHOULD and two MUST out and remove 
the 2119 citation.

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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Alvaro Retana]

On May 14, 2021 at 1:04:53 PM, Adrian Farrel wrote:


Hi!

I share some of John's concerns -- quick comment on the first one.


...
> > 1. There’s surprisingly little in this document that seems to be
> > SR-specific (and what there is, has some problems, see below). Is there
> > some reason you rule out interconnecting domains using other tunneling
> > technologies? I ask this question first because if the answer were to be
> > “oh huh, we don’t need to make this SR-specific after all” some of the
> > other things I’m asking about might go away.
>
> I'm sorry this isn't clear, but the use of other tunnelling technologies is
> very much in scope. As the Introduction says:
>
> The various ASes that provide connectivity between the Ingress and Egress
> Domains could each be constructed differently and use different technologies
> such as IP, MPLS with global table routing native BGP to the edge, MPLS IP
> VPN, SR-MPLS IP VPN, or SRv6 IP VPN.
>
> SR is used to identify the tunnels and provide end-to-end SR paths because the
> ingress and egress domains are SR domains, and the objective is to provide an
> end-to-end SR path.
>
> So we are not "making this SR aware" so much as enabling "SR-over-foo" using
> SIDs to identify the path segments that are tunnels.
>
> I don't know how to make this clearer except maybe using some red paint. We
> would write...
>
> The various ASes that provide connectivity between the Ingress and Egress
> Domains could each be constructed differently and use different technologies
> such as IP, MPLS with global table routing native BGP to the edge, MPLS IP
> VPN, SR-MPLS IP VPN, or SRv6 IP VPN. That is, the Ingress and Egress SR
> Domains can be connected by tunnels across a variety of technologies. This
> document describes how SR identifiers (SIDs) are use to identify the paths
> between the Ingress and Egress and the techniques in this document apply to
> routes of all AFI/SAFIs.

>From §5: "To achieve this, each Tunnel TLV in the Tunnel Encapsulation
attribute contains a Prefix SID sub-TLV [I-D.ietf-idr-tunnel-encaps]
for X."  But rfc9012 restricts the use of the Prefix-SID sub-TLV:

   [RFC8669] only defines behavior when the BGP Prefix-SID attribute is
   attached to routes of type IPv4/IPv6 Labeled Unicast
   [RFC4760][RFC8277], and it only defines values of the BGP Prefix-SID
   attribute for those cases.  Therefore, similar limitations exist for
   the Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE
   message for one of the address families for which [RFC8669] has a
   defined behavior, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760]
   [RFC8277].  If included in a BGP UPDATE for any other address family,
   it MUST be ignored.

IOW, even though the overall mechanism could not be SR-specific, the
SR solution can't be implemented in a general way (without more
consideration).

Alvaro.

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

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

[Alvaro Retana via Datatracker]

Alvaro Retana 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:
--

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



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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[John Scudder]

Hi Adrian,

Comments in line below.

> On May 14, 2021, at 1:04 PM, Adrian Farrel  wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
> Thanks for the careful review.
> 
>> 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.
> 
> I'm sorry this isn't clear, but the use of other tunnelling technologies is 
> very much in scope. As the Introduction says:
> 
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.
> 
> SR is used to identify the tunnels and provide end-to-end SR paths because 
> the ingress and egress domains are SR domains, and the objective is to 
> provide an end-to-end SR path.
> 
> So we are not "making this SR aware" so much as enabling "SR-over-foo" using 
> SIDs to identify the path segments that are tunnels.
> 
> I don't know how to make this clearer except maybe using some red paint.

That would be exclusionary to the colo(u)r-blind.

> We would write...
> 
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.  That is, the
>   Ingress and Egress SR Domains can be connected by tunnels across a
>   variety of technologies.  This document describes how SR identifiers
>   (SIDs) are use to identify the paths between the Ingress and Egress
>   and the techniques in this document apply to routes of all AFI/SAFIs.

If you want, you could expand the paragraph as you’ve suggested, but I don’t 
think it’s necessary — now that you’ve pointed out the paragraph, it’s clear 
enough. However, I think the document is still misleading and even inconsistent 
about this. Let me quote some other paragraphs to you.

Section 1:

   Segment Routing (SR) [RFC8402] is a protocol mechanism that can be
   used within a DC, and also for steering traffic that flows between
   two DC sites.  

The “steering traffic that flows between two DC sites” can easily be read as 
meaning, steering it *through* the backbone network. I take it your intent is 
to mean, steering it *over* the backbone network. 

   In order for a source (ingress) DC that uses SR to
   load balance the flows it sends to a destination (egress) DC, it
   needs to know the complete set of entry nodes (i.e., GWs) for that
   egress DC from the backbone network connecting the two DCs.  Note
   that it is assumed 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]) so
   that traffic engineering using SR may be used for these flows.

The requirement that the sites *and the backbone network connecting them* must 
all be part of the same BGP-LS instance caused me to raise my eyebrows up into 
my hairline, but there it is in the text. This surprising assumption (most 
service providers do not, to my knowledge, allow their customers to consume 
their LSDB), plus “traffic engineering using SR may be used for these flows”, 
plus the sentence noted above, led me a long way down the garden path of 
thinking you were proposing end-to-end SR forwarding.

And then we have Section 4:

   When a remote GW receives a route to a prefix X it uses the Tunnel
   Egress Endpoint Sub-TLVs in the containing Tunnel Encapsulation
   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*

(emphasis added). This serves to confirm my misapprehension that this is an 
exclusively SR solution. 

So now on the one hand, I accept that you were completely serious about the 
paragraph you quoted, and that I mentally elided, having been dazzled by the 
parts I just quoted. On the other hand, I wonder what I’m misunderstanding 
about the parts I’ve just quoted, or if I’m not misunderstanding them, how we 
can square this circle.

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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Hi John

I agree with your comments that the scenario I mentioned is covered in
Section 3 and agree as well on the RFC 2119 keyword usage scrub.

In-line

On Mon, May 17, 2021 at 3:55 PM John Scudder  wrote:

> Hi Gyan,
>
> > On May 17, 2021, at 1:50 PM, Gyan Mishra  wrote:
> >
> > So if GW2 connection to external was down but GW1 still has its
> connection to external.  GW2 would auto discover GW1 over iBGP and GW2
> would advertise both GW1 and GW2 as reachable gateways.  However GW2 has
> its external peer down.  So if GW1 continues to advertised GW2 as we stated
> GW1 will auto discover  GW2 over iBGP.
>
> Isn’t this scenario covered? From §3:
>
>If a gateway becomes disconnected from the backbone network, or if
>the SR domain operator decides to terminate the gateway's activity,
>it withdraws the advertisements described above.  This means that
>remote gateways at other sites will stop seeing advertisements from
>this gateway.


   Gyan> Yes.  Agreed.  I wanted to draw some more attention to this to the
authors on the withdrawal that it’s critical and agreed a MUST.

>
>
> So when GW2’s external peering goes down, GW2 withdraws its auto discovery
> route, and therefore GW1 re-advertises its routes externally without GW2
> listed in the tunnel attribute.
>




> I will say that reviewing the above-quoted text — which seems tailor-made
> for a “MUST withdraw” — made me notice that the draft makes only sporadic
> and desultory use of RFC2119 keywords. In fact there are so few used, that
> it seems like it might be better to scrub those two SHOULD and two MUST out
> and remove the 2119 citation.


Gyan> Agreed.  I will parse the draft for RFC 2119 keyword  placement  in
my final GEN-ART review update

>
>
> —John

-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)

[Alvaro Retana]

Éric:

Hi!

MSDP (from 2003) is an IPv4-only protocol.

Also, take a look at rfc4611/BCP121 (MSDP Deployment Scenarios) which
mentions other IPv6 alternatives which makes any extension of MSDP
unnecessary.


Alvaro.


On May 17, 2021 at 2:10:13 AM, Éric Vyncke wrote:

> == DISCUSS ==
> While I am an expert neither in multicast not in VPN, I wonder why this
> document is only about IPv4 and not a single word is written about IPv6.

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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Alvaro

Thank you for the added piece of information. I am clearing my DISCUSS tomorrow 
(past midnight here).

Regards

-éric

-Original Message-
From: iesg  on behalf of Alvaro Retana 

Date: Monday, 17 May 2021 at 23:34
To: Éric Vyncke via Datatracker , Eric Vyncke 
, The IESG 
Cc: Matthew Bocci , "Mankamana Mishra (mankamis)" 
, "bess-cha...@ietf.org" , 
"draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org" 
, "bess@ietf.org" 

Subject: Re: [bess] Éric Vyncke's Discuss on 
draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)

Éric:

Hi!

MSDP (from 2003) is an IPv4-only protocol.

Also, take a look at rfc4611/BCP121 (MSDP Deployment Scenarios) which
mentions other IPv6 alternatives which makes any extension of MSDP
unnecessary.


Alvaro.


On May 17, 2021 at 2:10:13 AM, Éric Vyncke wrote:

> == DISCUSS ==
> While I am an expert neither in multicast not in VPN, I wonder why this
> document is only about IPv4 and not a single word is written about IPv6.


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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Adrian

In the introduction it mentions the following backbone transport:

   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.


  In the draft it talks about SR steering

  however can RSVP be used in the backbone transport .


I think to clarify we should mention the MUST for the data plane
requirements for the backbone transport.


On the call last week we confirmed  that the ingress and egress
domains now called “sites” not domains do not have to be SR enabled.


Kind Regards


Gyan


On Mon, May 17, 2021 at 5:04 PM Gyan Mishra  wrote:

> Hi John
>
> I agree with your comments that the scenario I mentioned is covered in
> Section 3 and agree as well on the RFC 2119 keyword usage scrub.
>
> In-line
>
> On Mon, May 17, 2021 at 3:55 PM John Scudder  wrote:
>
>> Hi Gyan,
>>
>> > On May 17, 2021, at 1:50 PM, Gyan Mishra  wrote:
>> >
>> > So if GW2 connection to external was down but GW1 still has its
>> connection to external.  GW2 would auto discover GW1 over iBGP and GW2
>> would advertise both GW1 and GW2 as reachable gateways.  However GW2 has
>> its external peer down.  So if GW1 continues to advertised GW2 as we stated
>> GW1 will auto discover  GW2 over iBGP.
>>
>> Isn’t this scenario covered? From §3:
>>
>>If a gateway becomes disconnected from the backbone network, or if
>>the SR domain operator decides to terminate the gateway's activity,
>>it withdraws the advertisements described above.  This means that
>>remote gateways at other sites will stop seeing advertisements from
>>this gateway.
>
>
>Gyan> Yes.  Agreed.  I wanted to draw some more attention to this to
> the authors on the withdrawal that it’s critical and agreed a MUST.
>
>>
>>
>> So when GW2’s external peering goes down, GW2 withdraws its auto
>> discovery route, and therefore GW1 re-advertises its routes externally
>> without GW2 listed in the tunnel attribute.
>>
>
>
>
>
>> I will say that reviewing the above-quoted text — which seems tailor-made
>> for a “MUST withdraw” — made me notice that the draft makes only sporadic
>> and desultory use of RFC2119 keywords. In fact there are so few used, that
>> it seems like it might be better to scrub those two SHOULD and two MUST out
>> and remove the 2119 citation.
>
>
> Gyan> Agreed.  I will parse the draft for RFC 2119 keyword  placement  in
> my final GEN-ART review update
>
>>
>>
>> —John
>
> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Gyan Mishra]

Alvaro

Very good points brought up on the limitations on the tunnel encapsulation
attribute BGP prefix sid sub tlv.  Can only be used with BGP LU AFI / SAFI.

Kind Regards

Gyan


On Mon, May 17, 2021 at 4:12 PM Alvaro Retana 
wrote:

> On May 14, 2021 at 1:04:53 PM, Adrian Farrel wrote:
>
>
> Hi!
>
> I share some of John's concerns -- quick comment on the first one.
>
>
> ...
> > > 1. There’s surprisingly little in this document that seems to be
> > > SR-specific (and what there is, has some problems, see below). Is there
> > > some reason you rule out interconnecting domains using other tunneling
> > > technologies? I ask this question first because if the answer were to
> be
> > > “oh huh, we don’t need to make this SR-specific after all” some of the
> > > other things I’m asking about might go away.
> >
> > I'm sorry this isn't clear, but the use of other tunnelling technologies
> is
> > very much in scope. As the Introduction says:
> >
> > The various ASes that provide connectivity between the Ingress and Egress
> > Domains could each be constructed differently and use different
> technologies
> > such as IP, MPLS with global table routing native BGP to the edge, MPLS
> IP
> > VPN, SR-MPLS IP VPN, or SRv6 IP VPN.
> >
> > SR is used to identify the tunnels and provide end-to-end SR paths
> because the
> > ingress and egress domains are SR domains, and the objective is to
> provide an
> > end-to-end SR path.
> >
> > So we are not "making this SR aware" so much as enabling "SR-over-foo"
> using
> > SIDs to identify the path segments that are tunnels.
> >
> > I don't know how to make this clearer except maybe using some red paint.
> We
> > would write...
> >
> > The various ASes that provide connectivity between the Ingress and Egress
> > Domains could each be constructed differently and use different
> technologies
> > such as IP, MPLS with global table routing native BGP to the edge, MPLS
> IP
> > VPN, SR-MPLS IP VPN, or SRv6 IP VPN. That is, the Ingress and Egress SR
> > Domains can be connected by tunnels across a variety of technologies.
> This
> > document describes how SR identifiers (SIDs) are use to identify the
> paths
> > between the Ingress and Egress and the techniques in this document apply
> to
> > routes of all AFI/SAFIs.
>
> >From §5: "To achieve this, each Tunnel TLV in the Tunnel Encapsulation
> attribute contains a Prefix SID sub-TLV [I-D.ietf-idr-tunnel-encaps]
> for X."  But rfc9012 restricts the use of the Prefix-SID sub-TLV:
>
>[RFC8669] only defines behavior when the BGP Prefix-SID attribute is
>attached to routes of type IPv4/IPv6 Labeled Unicast


Gyan> RFC8669 limitation


3.1 .
Label-Index TLV

   The Label-Index TLV MUST be present in the BGP Prefix-SID attribute
   attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277
]).  It MUST
   be ignored when received for other BGP AFI/SAFI combinations.


RFC 9012 Tunnel encapsulation attribute

3.7 .
Prefix-SID Sub-TLV (Type Code 11)

   [RFC8669] defines a BGP path attribute known as the "BGP Prefix-SID
   attribute".  This attribute is defined to contain a sequence of one
   or more TLVs, where each TLV is either a Label-Index TLV or an
   Originator SRGB (Source Routing Global Block) TLV.

   This document defines a Prefix-SID (Prefix Segment Identifier) sub-
   TLV.  The Value field of the Prefix-SID sub-TLV can be set to any
   permitted value of the Value field of a BGP Prefix-SID attribute
   [RFC8669 ].

   [RFC8669] only defines behavior when the BGP Prefix-SID attribute is
   attached to routes of type IPv4/IPv6 Labeled Unicast
   [RFC4760 ][RFC8277],
and it only defines values of the BGP Prefix-SID
   attribute for those cases.  Therefore, similar limitations exist for
   the Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE
   message for one of the address families for which [RFC8669
] has a
   defined behavior, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760
]
   [RFC8277 ].  If
included in a BGP UPDATE for any other address family,
   it MUST be ignored.




>[RFC4760][RFC8277], and it only defines values of the BGP Prefix-SID
>attribute for those cases.  Therefore, similar limitations exist for
>the Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE
>message for one of the address families for which [RFC8669] has a
>defined behavior, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760]
>[RFC8277].  If included in a BGP UPDATE for any other address family,
>it MUST be ignored.
>
> IOW, even though the overall mechanism could not be SR-specific, the
> SR solution can't b

[bess] Éric Vyncke's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-msdp-sa-interoperation-06: 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-mvpn-msdp-sa-interoperation/



--
COMMENT:
--

Thank you Alvaro for explaining to me that MSDP is IPv4-only so this document
must be IPv4-only as well. I am now clearing my previous DISCUSS ballot.

Thanks to the authors, WG, and doc shepherd for the work done (though the text
is very hard to read, quite dense, and little context is given).

Regards

-éric



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

[bess] Murray Kucherawy's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-mvpn-msdp-sa-interoperation-06: 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-mvpn-msdp-sa-interoperation/



--
COMMENT:
--

The shepherd writeup asks "Why is this the proper type of RFC?" but the answer
to this question is missing.



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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)

[Gyan Mishra]

Chiming in.  Some history.

Due  to the complexities of ASM requirement for MSDP / RP for inter domain
multicast, IPv6 for simplicity as well as lessons learned with the
complexity of ASM was designed to support SSM only for inter domain
multicast.  Thus an MSDP extension was purposely never created for IPv6.


RFC 8815  came out last year  officially deprecating ASM / MSDP for inter
domain multicast with SSM replacement for inter domain multicast.

https://datatracker.ietf.org/doc/html/rfc8815

There is a big push worldwide for operators as well as customers to migrate
off ASM to SSM for OPEX savings.

Gyan

On Mon, May 17, 2021 at 6:11 PM Eric Vyncke (evyncke)  wrote:

> Alvaro
>
> Thank you for the added piece of information. I am clearing my DISCUSS
> tomorrow (past midnight here).
>
> Regards
>
> -éric
>
> -Original Message-
> From: iesg  on behalf of Alvaro Retana <
> aretana.i...@gmail.com>
> Date: Monday, 17 May 2021 at 23:34
> To: Éric Vyncke via Datatracker , Eric Vyncke <
> evyn...@cisco.com>, The IESG 
> Cc: Matthew Bocci , "Mankamana Mishra
> (mankamis)" , "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, "
> draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org" <
> draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org>, "bess@ietf.org" <
> bess@ietf.org>
> Subject: Re: [bess] Éric Vyncke's Discuss on
> draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)
>
> Éric:
>
> Hi!
>
> MSDP (from 2003) is an IPv4-only protocol.
>
> Also, take a look at rfc4611/BCP121 (MSDP Deployment Scenarios) which
> mentions other IPv6 alternatives which makes any extension of MSDP
> unnecessary.
>
>
> Alvaro.
>
>
> On May 17, 2021 at 2:10:13 AM, Éric Vyncke wrote:
>
> > == DISCUSS ==
> > While I am an expert neither in multicast not in VPN, I wonder why
> this
> > document is only about IPv4 and not a single word is written about
> IPv6.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Erik Kline via Datatracker]

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