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 protected]> wrote:
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.
BKH> Agree, sounds good.
>
> 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..
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 :)
> 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
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 protected]
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
