Subject: Re: [bess] FURTHER REMINDER Re: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-datacenter-gateway-04

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Jun 2020 17:36:16 +0100

Hi Boris,

We waited for a prompt for the chairs to find out what the disposition of the draft was.

> I read the draft and personally support its publication.

Thanks.

> Here are some comments:
>
> 1) Introduction part has the following statement: "Segment Routing (SR) [RFC8402]
>  is a popular protocol mechanism for use within a DC...". I would love to see SR as
>  popular mechanism within DC worldwide, but such statement requires either  a 
>  reference to some cases/examples of SR-baced DCs or, IMO, has to be changed
>  to something like "...become a popular mechanism..." 

Depends on the meaning of popular 😊

Changed text in Abstract to...
   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.
...and in the Introduction to...
   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.

>
> 2) Fig 1, IMO, needs additional information about which AS/ ASes
>  are used for Ingress and Egress SR Domains (Guess AS1 and AS2 
>  respectively, but it has to be shown). Current version looks a bit
>  confusing, for example, why we need AS3 on Fig.1?

I'm looking at the figure and I don't understand your confusion: sorry.
The ASes are not used for Ingress and Egress SR Domains. The two domains are marked separately.
Packets are routed from the Ingress SR domain to the Egress SR domain through the Gateways (also marked) and across the ASes that provide connectivity.

> 3) If new Tunnel Encapsulation is defined as SR Tunnel, will 
>  ietf-idr-tunnel-encaps be updated accordingly?  15th version
>  does not have it so far

I don't believe that other document needs to be updated.
The code point has already been assigned for this draft. You can see it at https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types

Best,
Adrian

---

From: Boris Hassanov <[email-masked]>
Date: Mon, 1 Jun 2020 18:28:13 +0000 (UTC)

Hi Adrian and all,
Thanks a lot for getting back.
My replies are inline, BKH>.
SY,Boris

    On Monday, June 1, 2020, 7:36:41 PM GMT+3, Adrian Farrel <[email-masked]> wrote:  
 
 Hi Boris,

Thanks.

BKH> Agree, sounds good.

I'm looking at the figure and I don't understand your confusion: sorry.
The ASes are not used for Ingress and Egress SR Domains. The two domains are marked separately.
Packets are routed from the Ingress SR domain to the Egress SR domain through the Gateways (also marked) and across the ASes that provide connectivity.
BKH>  The text after Fig.1 says about limitations of BGP Add-Path especially in Inter-AS case with ASBRs in regards to GW identity, but Fig.1 also have AS3, it makes some dissonance with that message, IMO. That is why I was confused. May be I was just too focused on details :)

BKH> Adrian, sorry, one last question:Part 3. SR Domain GW AD...To avoid the side effect of applying the Tunnel Encapsulation
   attribute to any packet that is addressed to the GW itself, the GW
   SHOULD use a different loopback address for the two cases.Am I correct that these two cases do mean: 1) Loopback for AD route 2) Loopback for other purposes (i.e. receiving packets addressed to the GW itself) ?
So GW should advertise 2 different loopbacks, one with Tunnel Encapsulation attribute and another without it.
Thanks again.

Best,
Adrian

_______________________________________________
BESS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bess

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Jun 2020 21:15:48 +0100

Hello again,

[snip]

>> The ASes are not used for Ingress and Egress SR Domains. The two

>> domains are marked separately.
>> Packets are routed from the Ingress SR domain to the Egress SR

>> domain through the Gateways (also marked) and across the ASes

>> that provide connectivity.

> BKH>  The text after Fig.1 says about limitations of BGP Add-Path

> especially in Inter-AS case with ASBRs in regards to GW identity,

> but Fig.1 also have AS3, it makes some dissonance with that

> message, IMO. That is why I was confused. May be I was just too

> focused on details :)

I’m not sure. Maybe if we had numbered the ASes differently so that the obvious least AS-hops (“shortest”) path was through AS1, and AS2/AS3 was the path that would lose the GW identities?

But I still don’t see the problem you are raising, and I really want to.

The figure shows that there are multiple possible routes from ingress domain to egress domain:

*	GW-AS3-GW2
*	GW-AS1-[choice of ASBRs]-AS2-GW1
*	GW-AS1-[choice of ASBRs]-AS2-GW2

The text notes that:

*	Add-Paths enables the presentation of {AS3} and {AS1, AS2} as paths
*	Add-Paths loses the identities and so choice of GW1 and GW2 in the {AS1, AS2} case

>> The code point has already been assigned for this draft. You can see

>> it at https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types

> Adrian, sorry, one last question:

> Part 3. SR Domain GW AD

>...

> To avoid the side effect of applying the Tunnel Encapsulation
> SHOULD use a different loopback address for the two cases.

> Am I correct that these two cases do mean: 

> 1) Loopback for AD route 

> 2) Loopback for other purposes (i.e. receiving packets addressed

>   to the GW itself) ?

> So GW should advertise 2 different loopbacks, one with Tunnel

> Encapsulation attribute and another without it.

Yes, you got it.

Best,

Adrian

---

From: Boris Hassanov <[email-masked]>
Date: Wed, 3 Jun 2020 19:34:39 +0000 (UTC)

Hi Adrian!My comment is below.
Thank you.
SY,Boris

 On Monday, June 1, 2020, 11:16:17 PM GMT+3, Adrian Farrel <[email-masked]> wrote:  

Hello again,

[snip]

   
   - GW-AS3-GW2
   - GW-AS1-[choice of ASBRs]-AS2-GW1
   - GW-AS1-[choice of ASBRs]-AS2-GW2

The text notes that:
   
   - Add-Paths enables the presentation of {AS3} and {AS1, AS2} as paths    

   - Add-Paths loses the identities and so choice of GW1 and GW2 in the {AS1, AS2} case

 BKH> I think, that t would be better to clarify the relationship between Ingress and Egress SR domains with AS1,AS2,AS3 from BGP point of view on FIg 1. Are they  just part of AS3 (so IBGP between GW and PE of AS3) or  separate ASes (EBGP), it will be much easier to understand the further steps in regards to why Add Path is not suitable there.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 4 Jun 2020 16:15:53 +0100

OK Boris, I get it (thanks to John for hitting me with an appropriately socially distanced piece of timber!).

Yes, we should consider the SR domains as ASes. Yes, I’ll add this note. Yes, I’ll update figure 1.

Best,

Adrian

From: Boris Hassanov <[email-masked]> 
Sent: 03 June 2020 20:35
To: [email-masked]; [email-masked]; Adrian Farrel <[email-masked]>; [email-masked]
Subject: Re: [bess] FURTHER REMINDER Re: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-datacenter-gateway-04

Hi Adrian!

My comment is below.

Thank you.

SY,

Boris

 

Hello again,

[snip]

*	GW-AS3-GW2

The text notes that: