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

[Ali Sajassi (sajassi)]

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:

  1.  Advertisements of routes learned over a local AC by a GW into the 
participating domains w/o a domain-path Attribute
  2.  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
  3.  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)" 
Date: Friday, December 11, 2020 at 7:37 AM
To: "draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org" 

Cc: "bess@ietf.org" , "bess-cha...@ietf.org" 

Subject: draft-ietf-bess-evpn-ipvpn-interworking chair review
Resent-From: 
Resent-To: , Cisco Employee , 
, , , 
, 
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/


  *   a) I agree with DJ’s comment on: “This attribute list may contain zero, 
one or more segments". It is actually one or more.
  *   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.
  *   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.
  *   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.

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.


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


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

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.


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

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.

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

The considerations about ASPATH look really implementation details to me (at 
least the way it is written). Basically the ASPATH propagation 

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Richard Vallee (rvallee)]

I support publishing draft-ietf-bess-srv6-services-05 draft as a standard track 
RFC.

This draft is already supported by several operators having deployed SRv6 
networks
to support real-time traffic for millions of customers.
Details are in 
https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/

Many thanks to the co-authors and everyone else contributing to 
draft-ietf-bess-srv6-services draft.

Thanks
Richard


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Monday, November 30, 2020 at 12:16 PM
To: 
"draft-ietf-bess-srv6-servi...@ietf.org"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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