Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Ravi,

Thank you for the review. We submitted rev 10.
Please see my comments below.

Thanks.
Jorge

From: Ravi Singh via Datatracker 
Date: Tuesday, December 22, 2020 at 12:04 PM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-proxy-arp-nd@ietf.org 
, last-c...@ietf.org 

Subject: Rtgdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09
Reviewer: Ravi Singh
Review result: Has Nits

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-bess-evpn-proxy-arp-nd
Reviewer: Ravi Singh
Review Date: 21 Dec 2020
Intended Status: Standards track (as listed on the draft)

Summary:

This document is basically ready for publication, but has nits that should be
considered prior to publication.

Comments:

The draft is generally well written and easy to understand.
It basically is a description to explain how ARP, ND, EVPN should work together
to reduce forwarding of ARP queries and/or NS messages, in an EVPN deployment,
by the use of gratuitous ARP/ND. The abstract, though, could be made more
direct by stating as such.
[jorge] changed the abstract as suggested by Russ.


Major Issues: none found.

Minor Issues: none found.

Nits:
1. Figure 1: please show which device owns IP3, for more clarity.
[jorge] done. Thanks.


2.  Section 4.6 (a):
a. "   IP moves before the timer expires (default value of N=5), it
   concludes that a duplicate IP situation has occurred.  An IP move". It
   would be nice to elaborate on why the default value of "5" is
   recommended. Why not 1? Too much thrashing? However, for the cases where
   there is no thrashing, having a value of 5 as default slows the DAD
   procedure. Any recommendation on how to address that?
[jorge] the default values are consistent with the mac duplication default 
values in RFC7432. The latter controls how fast a mac is considered as 
duplicate (by default), while in this document the number of moves and window 
values defines how fast an ip is considered as duplicate (by default). We think 
it is a good practice to have the same default values to detect duplicate macs 
and duplicate ips, and since the values are configurable, it should be fine for 
the operator to customize it to their specific use-case. Hope it is ok – these 
values are the default ones in some implementations following this document.

b.  Minor typo: "   owner and spoofer keep replying to the
CONFIRM message, the PE
   will detect the duplicate IP within the M timer:" ->
"  owner and spoofer keep replying to the CONFIRM message,
the PE
   will detect the duplicate IP within the M-second timer:"
[jorge] changed, thanks.


3. Biggest nit: the draft does not really specify any new messaging formats or
any new fields. It is basically saying how the existing ARP, ND, EVPN
messaging/machinery (should) work together to achieve flooding-minimization of
ARP/ND queries in EVPN. Given the foregoing, it is not clear to me if the draft
really should be considered "standards track" instead of "informational". The
chairs are requested to evaluate that.
[jorge] the draft was informational for quite a few versions. We only changed 
it to standards-track based on the reasoning of the AD who told us that, since 
the document is making explicit the RFC7432 procedures for proxy-arp/nd and 
updates 7432 in that respect, it should become standards-track. We, authors, 
see the AD’s point but have no issues going either way.


Best regards
Ravi

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

Re: [bess] Secdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Russ,

The references to SEND are not needed. It was just an example.
Since it is not appropriate, I removed the references to RFC 3971.

I also addressed your other editorial comments in the other email.
Thank you very much!
Jorge


From: Russ Housley via Datatracker 
Date: Tuesday, December 8, 2020 at 11:20 AM
To: sec...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-proxy-arp-nd@ietf.org 
, last-c...@ietf.org 

Subject: Secdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09
Reviewer: Russ Housley
Review result: Has Issues

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-bess-evpn-proxy-arp-nd-09
Reviewer: Russ Housley
Review Date: 2020-12-08
IETF LC End Date: 2020-12-15
IESG Telechat date: unknown

Summary: Has Issues


Major Concerns:  I worry about the reference to SEND (RFC 3971).  The
  SEND protocol only supports digital signatures using RSA with SHA-1.
  While this still might be adequate for the time scales associated
  with ND, the 80-bit security offered by SHA-1 is not considered
  adequate for digital signatures in general.  Is the reference to
  SEND really needed in this document?


Minor Concerns:  None


Nits:  The Gen-ART review by me includes some editorial suggestions.


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

Re: [bess] Genart last call review of draft-ietf-bess-evpn-proxy-arp-nd-09

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Russ,

Thank you for the review!
Please see my comments in-line with [jorge].

Thanks again!
Jorge

From: BESS  on behalf of Russ Housley via Datatracker 

Date: Friday, December 4, 2020 at 10:00 PM
To: gen-...@ietf.org 
Cc: draft-ietf-bess-evpn-proxy-arp-nd@ietf.org 
, bess@ietf.org 
, last-c...@ietf.org 
Subject: [bess] Genart last call review of draft-ietf-bess-evpn-proxy-arp-nd-09
Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-bess-evpn-proxy-arp-nd-09
Reviewer: Russ Housley
Review Date: 2020-12-04
IETF LC End Date: 2020-12-15
IESG Telechat date: unknown


Summary: Almost Ready


Major Concerns:

There is a normative downward reference to Informational RFC 6820.
It looks to me like this should be an informative reference.
[jorge] agreed. Changed.



Minor Concerns:

The Abstract seems very long.  I suggest:

   This document describes the EVPN Proxy-ARP/ND function, augmented
   by the capability of the ARP/ND Extended Community.  Together,
   these help operators of Internet Exchange Points (IXPs), Data
   Centers (DCs), and other networks deal with IPv4 and IPv6 address
   resolution issues associated with large Broadcast Domains (DBs) by
   reducing and even suppressing the flooding produced by address
   resolution in the EVPN network.
[jorge] ok, changed based on your suggestion.


Nits:

When there is a line break in the middle of "->", it is quite difficult
to read.  I hope there is a way to make the hyphen non-breaking.

s2.2: s/devices and therefore floods/devices, and therefore, floods/

s2.2: s/messages, however ARP/messages; however, ARP/

s6.5: s/IXP's peering network space/IXP peering network space/

s7: s/flooded, however the/flooded; however, the/

s7: s/will definitely protect/protects/
[jorge] done all the above, thanks.



IDnits reports:

  == The 'Updates: ' line in the draft header should list only the _numbers_
 of the RFCs which will be updated by this document (if approved); it
 should not include the word 'RFC' in the list.
[jorge] done, thanks.



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

[bess] I-D Action: draft-ietf-bess-evpn-proxy-arp-nd-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Operational Aspects of Proxy-ARP/ND in EVPN Networks
Authors : Jorge Rabadan
  Senthil Sathappan
  Kiran Nagaraj
  Greg Hankins
  Thomas King
Filename: draft-ietf-bess-evpn-proxy-arp-nd-10.txt
Pages   : 22
Date: 2021-01-04

Abstract:
   This document describes the EVPN Proxy-ARP/ND function, augmented by
   the capability of the ARP/ND Extended Community.  Together, these
   help operators of Internet Exchange Points (IXPs), Data Centers
   (DCs), and other networks deal with IPv4 and IPv6 address resolution
   issues associated with large Broadcast Domains (DBs) by reducing and
   even suppressing the flooding produced by address resolution in the
   EVPN network.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-proxy-arp-nd-10
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-proxy-arp-nd-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-proxy-arp-nd-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[bess] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-mvpn-evpn-aggregation-label

[IETF Secretariat]

Dear Zhaohui (Jeffrey) Zhang, Eric C. Rosen, Wen Lin, Zhenbin Li, IJsbrand 
Wijnands:


An IPR disclosure that pertains to your Internet-Draft entitled "MVPN/EVPN
Tunnel Aggregation with Common Labels"
(draft-ietf-bess-mvpn-evpn-aggregation-label) was submitted to the IETF
Secretariat on 2020-12-31 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/4571/). The title of the IPR disclosure is
"Huawei Technologies Co.,Ltd's Statement about IPR related to
draft-ietf-bess-mvpn-evpn-aggregation-label"


Thank you

IETF Secretariat


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

[bess] Last mile for WGLC on draft-ietf-bess-evpn-ipvpn-interworking-04 => need IDR review

[slitkows.ietf]

Hi IDR WG,

 

We are in the last mile for the WGLC of
draft-ietf-bess-evpn-ipvpn-interworking-04 in BESS WG.

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking

 

Couple of comments from our groups have been already addressed.

 

As BESS WG co-chair, I would like to get your feedback on the document.

 

There are couple of point that need to be looked at:

*   The draft defines a new path attributes DPATH for loop prevention
across "domains" (domain does not mean AS here).
*   It defines some propagation / non propagation rules of attributes by
the gateway PE (in uniform mode). I would like to spot your attention here.
One consequence is that for any new attribute defined in BESS or IDR, we'll
have to define the propagation rules by gateway PEs. I would like to hear
the opinion of the IDR group and IDR chairs on that point.
*   It defines aggregation rules of attributes in the context of the IP
VRF. I would like also to hear opinion from the group and chair on this.  

 

Thanks to provide your feedback as soon as possible (pls cross post in IDR
and BESS).

 

 

Brgds,

 

Stephane

 

 

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

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

[slitkows.ietf]

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)  
Sent: samedi 19 décembre 2020 13:17
To: Stephane Litkowski (slitkows) ;
draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org
Cc: bess@ietf.org; bess-cha...@ietf.org
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) mailto:saja...@cisco.com> >
Date: Monday, December 14, 2020 at 5:17 AM
To: Stephane Litkowski (slitkows) mailto:slitk...@cisco.com> >,
draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org

mailto:draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org> >
Cc: bess@ietf.org   mailto:bess@ietf.org> >, bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org> >
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)" mailto:slitk...@cisco.com> >
Date: Friday, December 11, 2020 at 7:37 AM
To: "draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org
 "
mailto:draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org> >
Cc: "bess@ietf.org  " mailto:bess@ietf.org> >, "bess-cha...@ietf.org
 " mailto:bess-cha...@ietf.org> >
Subject: draft-ietf-bess-evpn-ipvpn-interworking chair review
Resent-From: mailto:alias-boun...@ietf.org> >
Resent-To: mailto:jorge.raba...@nokia.com> >,
Cisco Employee mailto:saja...@cisco.com> >,
mailto:erose...@gmail.com> >, mailto:jdr...@juniper.net> >, mailto:w...@juniper.net>
>, mailto:ju1...@att.com> >, mailto:adam.1.simp...@nokia.com> >
Rese

[bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc-02

[Bocci, Matthew (Nokia - GB)]

This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc-02 [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 the 18th January 2021

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 are currently two IPR disclosures.

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-evpn-vpws-fxc/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-mvpn-evpn-aggregation-label-04

[slitkows.ietf]

We are still missing couple of IPR replies to close the WGLC: Eric, Ice
(their email contact has to be updated).

 

In addition, we haven't received any reply regarding an existing
implementation. Is anyone aware of an implementation ?

 

Brgds,

 

Stephane

 

 

 

 

From: BESS mailto:bess-boun...@ietf.org> > on behalf
of slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com> >
Date: Friday, December 11, 2020 at 4:53 PM
To: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org

mailto:draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org> >,
bess@ietf.org   mailto:bess@ietf.org>
>
Cc: bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org> >
Subject: [bess] WG Last Call, IPR and Implementation Poll for
draft-ietf-bess-mvpn-evpn-aggregation-label-04

This email starts a two-week working group last call for
draft-ietf-bess-mvpn-evpn-aggregation-label-04 [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 the 28th 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-mvpn-evpn-aggregation-label
/ 

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

 

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