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:
>
>
>
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
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
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
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
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
, and your spec would make
matters worse. It might be worth acknowledging this issue somewhere in the
document?”
I hope this is clearer now.
Thanks,
—John
> Cheers,
> Adrian
>
> From: John Scudder
> Sent: 14 May 2021 22:25
> To: Adrian Farrel
> Cc: The IESG ; draft-
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
> *Sub
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
Section 3 verbiage below describes the
re-advertisement of current set of GWs due to GW being added or deleted.
So the blackhole John mentioned due to a GW being disconnected from
backbone should not occur.
As described in Section 1
Adrian & Authors please correct me if I misspeak the way I read the draft.
I did not see in the draft stating explicitly how the internal DC GW routes
are advertised which I believe implicitly done via standard BGP AFI / SAFI
route propagation natively over the SR domain. So for example if the
Hi Adrian
I may have missed this in the draft but the solution for this failover
scenario is if each GW can only advertise itself, which I think that is
stated in section 3 then GW1 can only advertise itself via tunnel
encapsulation attribute and not GW2 as GW2 can only advertise itself when
it’s
Hi Adrian
I believe what John is describing is a valid failure scenario where one of
the GWs is no longer a valid gateway because it’s eBGP peering to core
domain is down, however the routing underlay is stable between the GWs
within the DC site. We are assuming the GWs at the site run an IGP to
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
Hi John,
The way I understood this is intending to work in practice is simply to
create IBGP session between GW1 & GW2,
If we have this IBGP session then there are two cases:
* we receive route to X from peer GW so we know peer GW can reach X hence
it is safe to advertise X with both GWs as NHs
Hi Adrian,
Thanks for your reply. Pressed for time at the moment but one partial response:
On May 14, 2021, at 1:04 PM, Adrian Farrel
mailto:adr...@olddog.co.uk>> wrote:
Agree with you that "stuff happens." I think that what you have described is a
window not a permanent situation.
When GW2
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
...@ietf.org; bess-cha...@ietf.org;
bess@ietf.org; Matthew Bocci ; matthew.bo...@nokia.com
Subject: John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with
DISCUSS and COMMENT)
John Scudder has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: Discuss
When
John Scudder 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
19 matches
Mail list logo
