Subject: Re: [bess] draft-ietf-bess-evpn-ipvpn-interworking chair review

From: <[email-masked]>
Date: Mon, 4 Jan 2021 12:14:21 +0100

Hi Jorge,

Thanks for the new version.

Few additional comments on the new text:

Section 4.

a.	“This attribute list may contain”. I think we can use “MAY contain”,
right ?

C) 2) The statement is unclear to me. Let’s say that I have an IGP route or
static route in the VRF that needs to be advertised in an EVPN or IPVPN
domain, does the statement mean that we are advertising the route with the
domain ID of the EVPN or IPVPN realm ? Could you clarify this particular
case ?  C.3) makes more sense to me.

e) uses “GW-PE” could use expand it as “GW-PE (gateway PE)” ?

g) for error handling, could you confirm that receiving an unknown ISF type
is not an error ?

Section 5.2:

Isn’t it dangerous to try to define which attributes needs to be propagated,
and which one should not be ? We are always creating new attributes, should
people update this doc each time a new attribute comes ? I don’t really see
how this could be managed.

[jorge] the reason is security again. We don’t want to blindly propagate
things across ISF domains. Only those things that help with best path
selection. An example of things you don’t want to simply blindly propagate
is BGP tunnel encapsulation attributes, route-targets, EVPN communities, bgp
prefix-sid attribute… by doing so, unexpected situations may happen. So yes,
we think future specs will need to say if ISF gateway PEs need to propagate
the new attribute or not.

[SLI] Let’s get some feedback from IDR people on this. I’m a bit afraid of
the tracking of updates… I agree that some attributes must not be propagated
or even does not make sense to be propagated.

Section 5.3:

Shouldn’t we just follow existing aggregation rules of each attribute ?
Again, what happens when new attributes are coming in. I don’t think that
the gateway function has actually something to change in the aggregation
process. Aggregation is happening in the VRF, there is no change compared to
what is existing today, for VRF, it’s just IP prefix aggregation.

[jorge] The aggregation per se is just IP aggregation, but the definition of
what to do with attributes on the aggregate is new, I think it needs to be
clearly specified.

[SLI] Right but this is orthogonal to this draft. The rules should exist on
a standard L3VPN PE.

Brgds,

Stephane

 

From: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]> 
Sent: samedi 19 décembre 2020 13:17
To: Stephane Litkowski (slitkows) <[email-masked]>;
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: draft-ietf-bess-evpn-ipvpn-interworking chair review

Stephane, all

After a few discussions, we published rev 04, which addresses all the
comments received, including Stephane’s comments.

Please see in-line.

Thanks!

Jorge

From: Ali Sajassi (sajassi) <[email-masked] <mailto:[email-masked]> >
Date: Monday, December 14, 2020 at 5:17 AM
To: Stephane Litkowski (slitkows) <[email-masked]
<mailto:[email-masked]> >,
[email-masked]
<mailto:[email-masked]>
<[email-masked]
<mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >, [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> >
Subject: Re: draft-ietf-bess-evpn-ipvpn-interworking chair review

Hi Stephane,

Jorge, John, DJ, and I met several times over the course of last two weeks
to address DJ and some of the other outstanding comments and in doing so
covering the following three cases as well:

a)       Advertisements of routes learned over a local AC by a GW into the
participating domains w/o a domain-path Attribute

b)      Advertisements of routes learned over a local AC by a GW into the
participating domains w/ a domain-path Attribute that contains a new SAFI
and new a domain-id

c)       Advertisements of routes learned over a local AC by a GW into the
participating domains w/ a domain-path Attribute that contains a new SAFI
and one of the existing domain-id

Jorge is working hard to incorporate the new changes and by end of the week
he should have a new rev that address all the comments including yours
below.

Cheers,

Ali

From: "Stephane Litkowski (slitkows)" <[email-masked]
<mailto:[email-masked]> >
Date: Friday, December 11, 2020 at 7:37 AM
To: "[email-masked]
<mailto:[email-masked]> "
<[email-masked]
<mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >, "[email-masked]
<mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: draft-ietf-bess-evpn-ipvpn-interworking chair review
Resent-From: <[email-masked] <mailto:[email-masked]> >
Resent-To: <[email-masked] <mailto:[email-masked]> >,
Cisco Employee <[email-masked] <mailto:[email-masked]> >,
<[email-masked] <mailto:[email-masked]> >, <[email-masked]
<mailto:[email-masked]> >, <[email-masked] <mailto:[email-masked]>
>, <[email-masked] <mailto:[email-masked]> >, <[email-masked]
<mailto:[email-masked]> >
Resent-Date: Friday, December 11, 2020 at 7:35 AM

Hi Authors,

Please find below my chair review related to
draft-ietf-bess-evpn-ipvpn-interworking.

BTW, you need to refresh the draft now, it has expired.

Section 3:

·         Nit:

s/uniqueness of the DOMAIN- ID/uniqueness of the DOMAIN-ID/

[jorge] fixed, thx

·         a) I agree with DJ’s comment on: “This attribute list may contain
zero, one or more segments". It is actually one or more.

[jorge] fixed, thx

·         The section 3 contains both normative and non-normative language.
If section 3 is intended to detail the normative behavior of
adding/modifying D-PATH, it must use normative for any of the normative
procedure. For instance b) may require normative language. While it is very
good to have an example in b), one or more clear normative rules are
required before talking about the example.

[jorge] ok, added more normative language.

·         b) talks about domain-ids attached to IP-VRF, this is fine.
However, the text should provide a wider view so people don’t think that
this is the only option. Domain-Ids may be assigned at VRF level, but also
at more a higher level (BGP peer), or even lower level (bgp community…). We
should not limit implementations here in the granularity domain-ids are
defined.

[jorge] check out the new text in (e)

·         c) I don’t see why “MUST NOT”, it does not hurt to have a
DOMAIN-ID associated with non ISF world (routes learned from IGP, static)…
there could be design where people do BGP one leg and non-BGP on the other
leg. We should probably relax that.

[jorge] check out the new text in (c)

Would you mind adding a beautiful ASCII-ART for the attribute format ? It’s
usually good to have when reading to see the attribute format rather than
having to read the text.

[jorge] done

You need to define the error handling procedures for D-PATH as per RFC7606
(you should have it as normative ref too).

[jorge] done, check out the new text in (g)

Section 3.1

This sentence is misleading and does not match with the normative behavior
of Section 3) d)

“In general, any interworking PE that imports an ISF route MUST flag
   the route as "looped" if its D-PATH contains a <DOMAIN-ID:ISF_SAFI_TYPE>
segment, where DOMAIN-ID matches a local DOMAIN-ID
   in the tenant IP-VRF.”

I don’t see the value of this section beyond providing an example. The
normative behavior is already given in Section 3) d). Can’t the example be
packed under d).

[jorge] ok, done.

Also the pointed sentence still refers to a DOMAIN-ID per VRF, which is not
good for a generic statement. My domain ID info could from the BGP peer
config. Again, this option of per VRF is fine, but this is not the only one
that can be implemented.

[jorge] agreed. See new text.

Section 4.1:

I don’t see why “no-propagation-mode” is the default mode. This is breaking
existing propagation of attributes from SAFI 1 to SAFI 128. When we have a
CE running BGP with a PE, the PE propagates the attributes (CTs, ASPATH,
MED…) coming from the CE. 

[jorge] the reason why it is the default mode is security (the security
section points out some risks of the propagation or attributes). In order to
not break existing RFC4364 implementations we added this:

“This is the default mode of operation for gateway PEs that re-export ISF
routes from any ISF SAFI into EVPN, and from EVPN into any other SAFI.” –
since there is no other spec for EVPN interworking, we should be fine.

This section creates some ambiguity about the D-PATH attribute. Based on
Section 3, D-PATH will be necessarily sent but received D-PATH may be
dropped and new one created but the text of section 4.1 makes me think that
it’s not the case in no-propagation mode.

I think setting D-PATH is orthogonal to the attribute propagation.

As section 4.1 tells, people may still want to rely on existing SoO for
instance in some case in this case D-PATH may not be added.

I think section 3 and 4.1 have to be more clear on the normative procedures
about D-PATH addition/modification.

[jorge] good point. I clarified section 3(b) - D-PATH MUST be added by the
gateway PE as long as the gateway works in uniform-propagation-mode.

Section 4.2:

Isn’t it dangerous to try to define which attributes needs to be propagated,
and which one should not be ? We are always creating new attributes, should
people update this doc each time a new attribute comes ? I don’t really see
how this could be managed.

[jorge] the reason is security again. We don’t want to blindly propagate
things across ISF domains. Only those things that help with best path
selection. An example of things you don’t want to simply blindly propagate
is BGP tunnel encapsulation attributes, route-targets, EVPN communities, bgp
prefix-sid attribute… by doing so, unexpected situations may happen. So yes,
we think future specs will need to say if ISF gateway PEs need to propagate
the new attribute or not.

Isn’t there an indentation issue starting “When propagating an ISD route to
a different ISF SAFI…” ?

[jorge] should be fixed now, thx

The considerations about ASPATH look really implementation details to me (at
least the way it is written). Basically the ASPATH propagation rules doesn’t
change and the gateway function itself does not modify the ASPATH.

Similarly, for the IBGP-only path attributes, the word “copy” looks really
implementation dependent. Why not telling that the advertised route should
keep the received iBGP-only attribute ?

[jorge] ok, I changed it with “keep”

You should also clarify considerations regarding rfc6368.

[jorge] not sure what you mean, would you suggest some text please?

Section 4.3:

Shouldn’t we just follow existing aggregation rules of each attribute ?
Again, what happens when new attributes are coming in. I don’t think that
the gateway function has actually something to change in the aggregation
process. Aggregation is happening in the VRF, there is no change compared to
what is existing today, for VRF, it’s just IP prefix aggregation.

[jorge] The aggregation per se is just IP aggregation, but the definition of
what to do with attributes on the aggregate is new, I think it needs to be
clearly specified.

However, as we are defining D-PATH, we can define aggregation rules related
to D-PATH.

[jorge] it is also included yes.

Section 5:

“For a given prefix advertised in one or more non-EVPN ISF routes, the
   BGP best path selection procedure will produce a set of "non-EVPN
   best paths".  For a given prefix advertised in one or more EVPN ISF
   routes, the BGP best path selection procedure will produce a set of
   "EVPN best paths". »

I think the EVPN vs non EVPN paths is a bit misleading. Couldn’t we simplify
say that we have best path selection at ISF level which inserts routes in
IP-VRF and then we have a new selection at VRF level.

[jorge] the new ISF SAFI is EVPN, and the new spec is the selection between
EVPN and non-EVPN. The rest of the ISF SAFIs and their interaction was
already there. That’s why we thought it was clearer to talk in terms of EVPN
and non-EVPN. Let us know if it is not ok.

Regarding the new tie-breakers:

It s not clear to me which steps tie breaks an IPVPN path vs an EVPN path
(composite PE case) that are equivalent (only ISF changes).

[jorge] if everything else is the same, step 4 would remove from
consideration the IPVPN path.

Section 7:

I agree with Suresh’s comment about the unclarity of the first bullet.

This document makes ISF 1 in the picture, so all the procedures defined in
the document are applicable to all the combinations of ISFs including SAFI1
<-> SAFI 128. So the text must be written carefully.

[jorge] check out the new text, we tried to capture SAFI 1 consistently
now..

Section 10:  This section should be at the top of the document.

[jorge] done

Section 11:

You need a security consideration section.

[jorge] done

Section 15:

IMO, intersubnet forwarding and prefix-adv drafts must be normative as they
are key components of the solution.

[jorge] ok, done

Pls update the draft and then I’ll ask IDR to have a review on the draft as
well.

Brgds,

Stephane

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 18 Jan 2021 10:36:55 +0000

Hi Stephane,

Thank you for following up.
Please see in-line.

Jorge

From: [email-masked] <[email-masked]>
Date: Monday, January 4, 2021 at 4:14 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>, 'Stephane Litkowski (slitkows)' <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: draft-ietf-bess-evpn-ipvpn-interworking chair review
Hi Jorge,

Section 4.

a)       “This attribute list may contain”. I think we can use “MAY contain”, right ?
[jorge] ok, will change in the next rev

C) 2) The statement is unclear to me. Let’s say that I have an IGP route or static route in the VRF that needs to be advertised in an EVPN or IPVPN domain, does the statement mean that we are advertising the route with the domain ID of the EVPN or IPVPN realm ? Could you clarify this particular case ?  C.3) makes more sense to me.
[jorge] c2 was specifically added to address a requirement brought up to the list. It is open to the operator if – in c2 – the ISF route uses the domain ID of the EVPN or the IPVPN domains.

e) uses “GW-PE” could use expand it as “GW-PE (gateway PE)” ?
[jorge] added for the next revision

g) for error handling, could you confirm that receiving an unknown ISF type is not an error ?
[jorge] added this, let me know if it is ok:
“Domains in the D-PATH attribute with unknown ISF_SAFI_TYPE values are accepted and not considered an error.”

Section 5.2:
Isn’t it dangerous to try to define which attributes needs to be propagated, and which one should not be ? We are always creating new attributes, should people update this doc each time a new attribute comes ? I don’t really see how this could be managed.
[jorge] the reason is security again. We don’t want to blindly propagate things across ISF domains. Only those things that help with best path selection. An example of things you don’t want to simply blindly propagate is BGP tunnel encapsulation attributes, route-targets, EVPN communities, bgp prefix-sid attribute… by doing so, unexpected situations may happen. So yes, we think future specs will need to say if ISF gateway PEs need to propagate the new attribute or not.

[SLI] Let’s get some feedback from IDR people on this. I’m a bit afraid of the tracking of updates… I agree that some attributes must not be propagated or even does not make sense to be propagated.
[jorge] ok

Section 5.3:
Shouldn’t we just follow existing aggregation rules of each attribute ? Again, what happens when new attributes are coming in. I don’t think that the gateway function has actually something to change in the aggregation process. Aggregation is happening in the VRF, there is no change compared to what is existing today, for VRF, it’s just IP prefix aggregation.
[jorge] The aggregation per se is just IP aggregation, but the definition of what to do with attributes on the aggregate is new, I think it needs to be clearly specified.

[SLI] Right but this is orthogonal to this draft. The rules should exist on a standard L3VPN PE.
[jorge] personally I still prefer if we have this somewhere, and this document seems to be appropriate (unless it is covered already somewhere else).

Brgds,

Stephane

To: Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]

Stephane, all

After a few discussions, we published rev 04, which addresses all the comments received, including Stephane’s comments.
Please see in-line.

Thanks!
Jorge

From: Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 14, 2020 at 5:17 AM
To: Stephane Litkowski (slitkows) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-bess-evpn-ipvpn-interworking chair review
Hi Stephane,

Jorge, John, DJ, and I met several times over the course of last two weeks to address DJ and some of the other outstanding comments and in doing so covering the following three cases as well:

a)       Advertisements of routes learned over a local AC by a GW into the participating domains w/o a domain-path Attribute

b)      Advertisements of routes learned over a local AC by a GW into the participating domains w/ a domain-path Attribute that contains a new SAFI and new a domain-id

c)       Advertisements of routes learned over a local AC by a GW into the participating domains w/ a domain-path Attribute that contains a new SAFI and one of the existing domain-id

Jorge is working hard to incorporate the new changes and by end of the week he should have a new rev that address all the comments including yours below.

Cheers,
Ali

From: "Stephane Litkowski (slitkows)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 11, 2020 at 7:37 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: draft-ietf-bess-evpn-ipvpn-interworking chair review
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Friday, December 11, 2020 at 7:35 AM

Hi Authors,

Please find below my chair review related to draft-ietf-bess-evpn-ipvpn-interworking.

Section 3:

·         Nit:

·         a) I agree with DJ’s comment on: “This attribute list may contain zero, one or more segments". It is actually one or more.
[jorge] fixed, thx

·         The section 3 contains both normative and non-normative language. If section 3 is intended to detail the normative behavior of adding/modifying D-PATH, it must use normative for any of the normative procedure. For instance b) may require normative language. While it is very good to have an example in b), one or more clear normative rules are required before talking about the example.
[jorge] ok, added more normative language.

·         b) talks about domain-ids attached to IP-VRF, this is fine. However, the text should provide a wider view so people don’t think that this is the only option. Domain-Ids may be assigned at VRF level, but also at more a higher level (BGP peer), or even lower level (bgp community…). We should not limit implementations here in the granularity domain-ids are defined.
[jorge] check out the new text in (e)

·         c) I don’t see why “MUST NOT”, it does not hurt to have a DOMAIN-ID associated with non ISF world (routes learned from IGP, static)… there could be design where people do BGP one leg and non-BGP on the other leg. We should probably relax that.
[jorge] check out the new text in (c)

Would you mind adding a beautiful ASCII-ART for the attribute format ? It’s usually good to have when reading to see the attribute format rather than having to read the text.
[jorge] done

You need to define the error handling procedures for D-PATH as per RFC7606 (you should have it as normative ref too).
[jorge] done, check out the new text in (g)

Section 3.1
This sentence is misleading and does not match with the normative behavior of Section 3) d)

   the route as "looped" if its D-PATH contains a <DOMAIN-ID:ISF_SAFI_TYPE> segment, where DOMAIN-ID matches a local DOMAIN-ID

   in the tenant IP-VRF.”

I don’t see the value of this section beyond providing an example. The normative behavior is already given in Section 3) d). Can’t the example be packed under d).
[jorge] ok, done.

Also the pointed sentence still refers to a DOMAIN-ID per VRF, which is not good for a generic statement. My domain ID info could from the BGP peer config. Again, this option of per VRF is fine, but this is not the only one that can be implemented.
[jorge] agreed. See new text.

Section 4.1:
I don’t see why “no-propagation-mode” is the default mode. This is breaking existing propagation of attributes from SAFI 1 to SAFI 128. When we have a CE running BGP with a PE, the PE propagates the attributes (CTs, ASPATH, MED…) coming from the CE.
[jorge] the reason why it is the default mode is security (the security section points out some risks of the propagation or attributes). In order to not break existing RFC4364 implementations we added this:
“This is the default mode of operation for gateway PEs that re-export ISF routes from any ISF SAFI into EVPN, and from EVPN into any other SAFI.” – since there is no other spec for EVPN interworking, we should be fine.

This section creates some ambiguity about the D-PATH attribute. Based on Section 3, D-PATH will be necessarily sent but received D-PATH may be dropped and new one created but the text of section 4.1 makes me think that it’s not the case in no-propagation mode.
I think setting D-PATH is orthogonal to the attribute propagation.
As section 4.1 tells, people may still want to rely on existing SoO for instance in some case in this case D-PATH may not be added.
I think section 3 and 4.1 have to be more clear on the normative procedures about D-PATH addition/modification.
[jorge] good point. I clarified section 3(b) - D-PATH MUST be added by the gateway PE as long as the gateway works in uniform-propagation-mode.

Section 4.2:
Isn’t it dangerous to try to define which attributes needs to be propagated, and which one should not be ? We are always creating new attributes, should people update this doc each time a new attribute comes ? I don’t really see how this could be managed.
[jorge] the reason is security again. We don’t want to blindly propagate things across ISF domains. Only those things that help with best path selection. An example of things you don’t want to simply blindly propagate is BGP tunnel encapsulation attributes, route-targets, EVPN communities, bgp prefix-sid attribute… by doing so, unexpected situations may happen. So yes, we think future specs will need to say if ISF gateway PEs need to propagate the new attribute or not.

Isn’t there an indentation issue starting “When propagating an ISD route to a different ISF SAFI…” ?
[jorge] should be fixed now, thx

The considerations about ASPATH look really implementation details to me (at least the way it is written). Basically the ASPATH propagation rules doesn’t change and the gateway function itself does not modify the ASPATH.

Similarly, for the IBGP-only path attributes, the word “copy” looks really implementation dependent. Why not telling that the advertised route should keep the received iBGP-only attribute ?
[jorge] ok, I changed it with “keep”
You should also clarify considerations regarding rfc6368.
[jorge] not sure what you mean, would you suggest some text please?

Section 4.3:
Shouldn’t we just follow existing aggregation rules of each attribute ? Again, what happens when new attributes are coming in. I don’t think that the gateway function has actually something to change in the aggregation process. Aggregation is happening in the VRF, there is no change compared to what is existing today, for VRF, it’s just IP prefix aggregation.
[jorge] The aggregation per se is just IP aggregation, but the definition of what to do with attributes on the aggregate is new, I think it needs to be clearly specified.

However, as we are defining D-PATH, we can define aggregation rules related to D-PATH.
[jorge] it is also included yes.

Section 5:

   "EVPN best paths". »

I think the EVPN vs non EVPN paths is a bit misleading. Couldn’t we simplify say that we have best path selection at ISF level which inserts routes in IP-VRF and then we have a new selection at VRF level.
[jorge] the new ISF SAFI is EVPN, and the new spec is the selection between EVPN and non-EVPN. The rest of the ISF SAFIs and their interaction was already there. That’s why we thought it was clearer to talk in terms of EVPN and non-EVPN. Let us know if it is not ok.

Regarding the new tie-breakers:
It s not clear to me which steps tie breaks an IPVPN path vs an EVPN path (composite PE case) that are equivalent (only ISF changes).
[jorge] if everything else is the same, step 4 would remove from consideration the IPVPN path.

Section 7:

I agree with Suresh’s comment about the unclarity of the first bullet.
This document makes ISF 1 in the picture, so all the procedures defined in the document are applicable to all the combinations of ISFs including SAFI1 <-> SAFI 128. So the text must be written carefully.
[jorge] check out the new text, we tried to capture SAFI 1 consistently now..

Section 11:

Section 15:
IMO, intersubnet forwarding and prefix-adv drafts must be normative as they are key components of the solution.
[jorge] ok, done

Pls update the draft and then I’ll ask IDR to have a review on the draft as well.

Brgds,

Stephane

---

From: "Stephane Litkowski (slitkows)" <[email-masked]>
Date: Mon, 18 Jan 2021 19:43:06 +0000

Hi Jorge,

On the aggregation side , I agree it should be somewhere, but I don t think this doc is the right place. IP prefix aggregation rules are available for Internet too, I was more seeing this  done at IDR if any catchup is required. I m still trying to get Sue or John feedbacks.

Will let you know.

thanks for all the improvements done in the doc anyway.

Stephane

Téléchargez Outlook pour iOS<https://aka.ms/o0ukef>
________________________________
De : Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Envoyé : Monday, January 18, 2021 11:36:55 AM
À : [email-masked] <[email-masked]>; Stephane Litkowski (slitkows) <[email-masked]>; [email-masked] <[email-masked]>
Cc : [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Objet : Re: draft-ietf-bess-evpn-ipvpn-interworking chair review

Hi Stephane,

Please see in-line.

Jorge

Hi Jorge,

Section 4.

Section 5.2:

[jorge] ok

Section 5.3:

Brgds,

Stephane

Stephane, all

Please see in-line.

Thanks!

Jorge

Hi Stephane,

Cheers,

Ali

Hi Authors,

Section 3:

·         Nit:

[jorge] fixed, thx

[jorge] fixed, thx

[jorge] done

Section 3.1

   in the tenant IP-VRF.”

[jorge] ok, done.

Section 4.1:

Section 4.2:

Section 4.3:

Section 5:

   "EVPN best paths". »

Section 7:

[jorge] done

Section 11:

[jorge] done

Section 15:

[jorge] ok, done

Brgds,

Stephane