Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEECC14F6BC; Sat, 9 Nov 2024 08:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJy6U7QU2gEU; Sat, 9 Nov 2024 08:29:28 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58C6C14F748; Sat, 9 Nov 2024 08:29:28 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2e2b549799eso2633693a91.3; Sat, 09 Nov 2024 08:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731169768; x=1731774568; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=JXtu+ErYFAtwcpxrpii7as7wsyYfemH86bUJWMM4IeA=; b=klGQBwOTMC9VqWerB9hSEgTvCMVOSbdZKOydA98xzvOMV+k/oRjwD+u8Oko1d00/pE LM8IzA0vMsDV/7kJfNq17LXQ9hBQqrTsGcpMQCsZNt6oNrziOgOLWgEE+7ZrALhckL2l fnuW83Lm2pJiS6lCkMU4IxujaqhyO4qS1CIY7UM5ZW/NL90ZPT+s9iQGOI+qMOcubDcU AQJZd9OfqfxD6Z5rimzUG8L6fw7V5L/1FOwlP7V5rOyjpdJ+VEs6Y9DR22OPTN3+4iHn rP7EHQcIM0CYuYmTXONlxmY1Sl/81u5ceP3lVkxlRxM08nN+U+qhCIt8GhEgpS1o7ndq TaqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731169768; x=1731774568; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JXtu+ErYFAtwcpxrpii7as7wsyYfemH86bUJWMM4IeA=; b=UE/lcJOs/bGmNsATnokkC02otlEFvy+uPUdldoQn4D5vzmwwBF6O1OMUieTvcDbP1z 7c+XS1gc/xb4pT//36visWPYAWwevRvAYe6Mv4l3yWHXbfpuO4TMBCrMWM9kiKYdVQGL KxaCrYOtPVP+qJBw25ZfxD6StTNzw51YP/KxNeSwrHl18qqhO6eivYmsX+cJI4BA/zQ5 TyVjsmEnK+IcoXdq+rybxWhk5YIDR0XLrA5o+Y5uE2IEjTda2rDvBhqG3klu+GV0O8s8 6lT0VQAU42VDvcdHaghFZ8/YbB4CdWAklsJrutqB53k00oxd3cJM3sxksZ0ljdTp4AO8 nsvA== X-Forwarded-Encrypted: i=1; AJvYcCWZHWVvKv4ONSwBvB2SlerOFqylJlBgeYir2OLPn1Z3j/CjUvIgIKhuZS9WKC/MGC+UKcR4@ietf.org X-Gm-Message-State: AOJu0YxwDVXS9Fs3wg9wLhW7Qo6gZiXYnaLRi53hW8B4anwgUGLEVoZR 0lK2tQ92hzmGRkKSVz4bRr+OkJUOmVmGVgNBK3NhctWIzW49ahCvLIU28Q== X-Google-Smtp-Source: AGHT+IG8l7p29zTnYncyo6ddHxd0eguHI1bjO/ScUfqq7SqBMedBpWu1vrxJFsdR9JmeSRBk3WmZJA== X-Received: by 2002:a17:90b:4a0d:b0:2e2:9077:a3b4 with SMTP id 98e67ed59e1d1-2e9b16e2740mr9737327a91.7.1731169767753; Sat, 09 Nov 2024 08:29:27 -0800 (PST) Received: from smtpclient.apple (c-73-241-100-20.hsd1.ca.comcast.net. [73.241.100.20]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21177ddf6ccsm48271715ad.85.2024.11.09.08.29.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Nov 2024 08:29:27 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9DC28270-A9FC-4212-988B-2F65486538AE Content-Transfer-Encoding: 7bit From: Neeraj Malhotra Mime-Version: 1.0 (1.0) Date: Sat, 9 Nov 2024 08:29:16 -0800 Message-Id: <9E3E527A-7669-48CA-994D-C7292ADE0F08@gmail.com> References: In-Reply-To: To: Gunter van de Velde X-Mailer: iPhone Mail (22B83) Message-ID-Hash: BWW5FTRM4ANX7XVOWJKW5C2WSLRCZCVM X-Message-ID-Hash: BWW5FTRM4ANX7XVOWJKW5C2WSLRCZCVM X-MailFrom: neeraj.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-ietf-bess-evpn-irb-extended-mobility@ietf.org, BESS X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_=5BShepherding_AD_review=5D_review_of_draft-ietf-?= =?utf-8?q?bess-evpn-irb-extended-mobility-17?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail-9DC28270-A9FC-4212-988B-2F65486538AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Great, many thanks Gunter for comments again. Neeraj > On Oct 29, 2024, at 5:51=E2=80=AFAM, Gunter van de Velde (Nokia) wrote: >=20 > =EF=BB=BF > Hi Neeraj, > =20 > Thanks for considering the feedbacks. > =20 > I requested IETF LC and moved the document into the next phase of the proc= essing pipeline. > =20 > G/ > =20 > From: Neeraj Malhotra > Sent: Thursday, October 17, 2024 1:03 AM > To: Gunter van de Velde (Nokia) > Cc: draft-ietf-bess-evpn-irb-extended-mobility@ietf.org; BESS > Subject: Re: [bess] [Shepherding AD review] review of draft-ietf-bess-evpn= -irb-extended-mobility-17 > =20 > =20 > CAUTION: This is an external email. Please be very careful when clicking l= inks or opening attachments. See the URL nok.it/ext for additional informati= on. > =20 >=20 > =20 > Hi Gunter, > =20 > Apologies again for taking some time and many thanks for a very detailed r= eview to improve the draft readability as well as some very good comments. C= ategorization of comments as [major], [minor], [re-edit] really helps. > =20 > I have uploaded a rev18 that: > =20 > Incorporates all the suggested [re-edit] comments. Many thanks for taking t= he time to provide all text improvements that significantly improve the over= all readability. > Addresses all of the [minor] and [major] comments, except for a few except= ions that are answered below. For clarity, I am enumerating all [major] and [= minor] comments below to explicitly mark the comments that are addressed in r= ev18 and exceptions that are explained below. > =20 > > [major] > > This abstract is very detailed and makes it hard to understand on a high= > > level what exactly the content of the draft is all about. I view upon a > > abstract as the textblob one gives to your people manager to make him/he= t > > understand what the document is all about. What about the following > > abstract textblob proposal, making high level draft intent better > > understandable for non-EVPN technology wizards > =20 > [NM]: corrected. Have re-written the abstract taking some parts from your p= roposed text. > =20 > > [minor] > > What about section 5? it exists in the draft. I assume the intent is > > informational > =20 > [NM]: corrected. Added section 5 as informational that serves as a foundat= ion for specifications in subsequent sections. > =20 > > [major] > > Is SRv6 intentionally missing from this list? > =20 > [NM]: corrected. added SRv6 as one of the overlay encapsulations. Procedur= es in this spec are applicable independent of the overlay encapsulation. > =20 > > [major] > > I believe that this is ambigious terminology. add RFC references to the > > base RFC that documents each type of overlay PE > =20 > [NM]: redefined the term =E2=80=9COverlay=E2=80=9D in the terminology sect= ion as =E2=80=9CL3 and L2 Virtual Private Network (VPN) enabled via NVO, SRv= 6, or MPLS service layer encapsulation=E2=80=9D. Let me know if this is clea= r. > =20 > > [minor] > > s/physical Ethernet/Physical ethernet/ > =20 > [NM]: corrected. > =20 > > 258 * RT-5: EVPN route type 5 carrying IP prefix reachability. > > > > [minor] > > add references to RFC7432 > =20 > [NM]: corrected. > =20 > > 260 * MAC-IP: IP association for a MAC, referred to in this > > document may > > 261 be IPv4, IPv6 or both. > > > > [minor] > > Is this specified in a document somewhere, or is this explicit to this > > document itself? > =20 > [NM]: It is used in a few other drafts in a different context. Definition i= n this document is to emphasize that when used in this document, it refers t= o both IPv4 and IPv6. I have redefined it as follows to make it clearer =E2=80= =93 =E2=80=9CIPv4 and/or IPv6 address and MAC binding for an overlay host.=E2= =80=9D > =20 > > 273 * SYNC MAC-IP sequence number: In the context of EVPN > > multi-homing, > > 274 this refers to sequence number received with a SYNC MAC-IP= > > route. > > > > > > [minor] > > Is the SYNC something outlined in this draft itself, or is this procedur= e > > specified in another document? > > I assume this is based upon the priciples of RFC7432 using the MAC > > Mobility Extended Community > =20 > [NM]: yes, SYNC terminology is specifically defined and used in this draft= . Not aware of this terminology being used in another draft or RFC. > =20 > 523 all PE devices that the ES is multi-homed to. There is nee= d for a > 524 mechanism to ensure consistency of sequence numbers assigne= d across > 525 these PEs. > =20 > [major] > * The text talks about PE3 and PE4 and about ESI-2, but the figure does no= t show this. > Can figure be corrected to show these components? > This will make it more clear how inconsistency with sequence numbers manif= ests. > =20 > [NM]: corrected. > =20 > [minor] > unsure why in thi informational section in the last paragraph uppercase MU= ST is used. BCP14 language does not apply to informational textblobs > =20 > [NM]: corrected. > =20 > 859 local OR remote. The MAC-IP to MAC parent relationship des= cribed > 860 earlier in this document in section 5.1 MAY be used to achi= eve this > 861 logic. > =20 > [major] > * for my own understanding: in section 6.2 first bullet point, make me won= der if the connected ESI is share between two PEs. Would the requirement pot= entially lead to a count to infinity when two PEs connect to a shared ESI? > =20 > [NM]: Local MAC sequence number assignment method listed in this section i= s intended to synchronize the sequence numbers between multi-homing PEs that= share the ESI if the local MAC sequence number is less than what is receive= d from the other PE. It is not intended to increment the sequence number bey= ond what is received from the other PE. I have elaborated the text for this i= n this section to make this clearer.=20 > =20 > * section 6.6: How would an implementation detect that the remote implemen= tation does not support the behavior? Could that be explicit explained in th= e text? > =20 > [NM]: Corrected. This section is essentially a specification on how a rem= ote MAC sequence number must be interpreted if different sequence numbers ar= e received for MAC and MAC-IP from the same remote PE. Implementing this spe= cification ensures that the PE will be able to interoperate with another PE t= hat does not synchronize sequence numbers between MAC and MAC-IP (using inhe= ritance). It does not require any explicit knowledge of the remote PE being c= ompliant or non-compliant or for this logic to be conditional based on remot= e PE=E2=80=99s compliance. I have updated the text to be clearer in this reg= ard. > =20 > * section 6.7: THis section i did not understand. Too many moving parts. C= an this be explained more explicit or elaborative? > =20 > [NM]: Corrected. updated the section to explain the scenario and remediati= on better. > =20 > * section 6.8: What network figure is referenced towards? > =20 > [NM]: There is no figure attached to this section. PE1 and PE2 are used as= two example PEs in the network to illustrate the mobility convergence scena= rios in this section. I have updated the section to say this. > =20 > 909 hosts advertised via NA messages with 0-bit=3D0. Please re= fer to > 910 [RFC9161]. > =20 > [major] > * Unsure what purpose of 0-bit=3D0 is and where it is explained in RFC9161= . Some explicit reference and explanation could help the draft=20 > =20 > [NM]: Corrected. This is a good catch. There was a typo in the draft (shou= ld be O bit / flag and not 0-bit). This refers to Override flag in NA messag= es. Reference in this draft is essentially to maintain the behavior defined= in RFC 9161, which is to not apply EVPN mobility and duplicate address dete= ction procedures to anycast IPv6 hosts learnt via NA with O flag set to 0. I= have fixed the typo in the draft to explicitly refer to Override Flag (O Fl= ag) so it can be clearly mapped to handling specified in RFC 9161. > =20 > 1083 need for a route clearing CLI for recovery from duplicate / f= rozen > 1084 state is truly optional. > =20 > [major] > * what is the 0-bit=3D0? please add a specific reference > =20 > [NM]: corrected. Same as above. > =20 > =20 > Please do let me know if we need to revisit any of the comments above or a= nything new comes up. > =20 > Thanks, > Neeraj=20 --Apple-Mail-9DC28270-A9FC-4212-988B-2F65486538AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

Great= , many thanks Gunter for comments again.

Neeraj

On Oct 29, 2024, at 5:= 51=E2=80=AFAM, Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com= > wrote:

=EF=BB=BF

Hi Neeraj,

 

Thanks for considering the feedbacks.

 

I requested IETF LC and moved the document into the ne= xt phase of the processing pipeline.

 

G/

 

From: Nee= raj Malhotra <neeraj.ietf@gmail.com>
Sent: Thursday, October 17, 2024 1:03 AM
To: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com>=
Cc: draft-ietf-bess-evpn-irb-extended-mobility@ietf.org; BESS <bes= s@ietf.org>
Subject: Re: [bess] [Shepherding AD review] review of draft-ietf-bess= -evpn-irb-extended-mobility-17

 

 

CAUTION: This is an external email. Please be very careful when clicking links= or opening attachments. See the URL nok.it/ext for additional information.<= o:p>

 

 

Hi Gunte= r,

=

 

Apologie= s again for taking some time and many thanks for a very detailed review to i= mprove the draft readability as well as some very good comments. Categorizat= ion of comments as [major], [minor], [re-edit] really helps.=

 

I have u= ploaded a rev18 that:

 

  • Incorporates all the suggested [re-edit] co= mments. Many thanks for taking the time to provide all text improvements tha= t significantly improve the overall readability.
  • Addresses all of the [minor] and [major] co= mments, except for a few exceptions that are answered below. For clarity, I a= m enumerating all [major] and [minor] comments below to explicitly mark the c= omments that are addressed in rev18 and exceptions that are explained below.

 

> [ma= jor]
> This abstract is very detailed and makes it hard to understand on a hig= h
> level what exactly the content of the draft is all about. I view upon a=
> abstract as the textblob one gives to your people manager to make him/h= et
> understand what the document is all about. What about the following
= > abstract textblob proposal, making high level draft intent better
> understandable for non-EVPN technology wizards

 

[NM]: co= rrected. Have re-written the abstract taking some parts from your proposed t= ext.

 

> [mi= nor]
> What about section 5? it exists in the draft. I assume the intent is > informational<= /o:p>

 

[NM]: co= rrected. Added section 5 as informational that serves as a foundation for sp= ecifications in subsequent sections.

 

> [ma= jor]
> Is SRv6 intentionally missing from this list?

 

[NM]: co= rrected. added SRv6 as one of the overlay encapsulations. Procedures in this= spec are applicable independent of the overlay encapsulation.

 

> [ma= jor]
> I believe that this is ambigious terminology. add RFC references to the=
> base RFC that documents each type of overlay PE

 

[NM]: re= defined the term =E2=80=9COverlay=E2=80=9D in the terminology section as =E2= =80=9CL3 and L2 Virtual Private Network (VPN) enabled via NVO, SRv6, or MPLS= service layer encapsulation=E2=80=9D. Let me know if this is clear.<= span style=3D"font-size:13.5pt;color:black">

 

> [mi= nor]
> s/physical Ethernet/Physical ethernet/

 

[NM]: co= rrected.

 

> 258=         *  RT-5: EVPN route type 5 c= arrying IP prefix reachability.
>
> [minor]
> add references to RFC7432

 

[NM]: co= rrected.

 

> 260=         *  MAC-IP: IP association fo= r a MAC, referred to in this
> document may
> 261           be IPv4= , IPv6 or both.
>
> [minor]
> Is this specified in a document somewhere, or is this explicit to this<= br> > document itself?

 

[NM]: It= is used in a few other drafts in a different context. Definition in this do= cument is to emphasize that when used in this document, it refers to both IP= v4 and IPv6. I have redefined it as follows to make it clearer =E2=80=93 =E2=80=9CIPv4 and/or IPv6 address a= nd MAC binding for an overlay host.=E2=80=9D

 

> 273=         *  SYNC MAC-IP sequence numb= er: In the context of EVPN
> multi-homing,
> 274           this re= fers to sequence number received with a SYNC MAC-IP
> route.
>
>
> [minor]
> Is the SYNC something outlined in this draft itself, or is this procedu= re
> specified in another document?
> I assume this is based upon the priciples of RFC7432 using the MAC
> Mobility Extended Community

 

[NM]: ye= s, SYNC terminology is specifically defined and used in this draft. Not awar= e of this terminology being used in another draft or RFC.

 

523 = ;           all PE devices that= the ES is multi-homed to.  There is need for a

524 = ;           mechanism to ensure= consistency of sequence numbers assigned across

525 = ;           these PEs.

 

[major]<= /span>

* The te= xt talks about PE3 and PE4 and about ESI-2, but the figure does not show thi= s.

=

Can figu= re be corrected to show these components?

This wil= l make it more clear how inconsistency with sequence numbers manifests.

 

[NM]: co= rrected.

 

[minor]<= /span>

unsure w= hy in thi informational section in the last paragraph uppercase MUST is used= . BCP14 language does not apply to informational textblobs

 

[NM]: co= rrected.

 

859 = ;           local OR remote.&nb= sp; The MAC-IP to MAC parent relationship described

860 = ;           earlier in this doc= ument in section 5.1 MAY be used to achieve this

861 = ;           logic.

 

[major]<= /span>

* for my= own understanding: in section 6.2 first bullet point, make me wonder if the= connected ESI is share between two PEs. Would the requirement potentially l= ead to a count to infinity when two PEs connect to a shared ESI?

 

[NM]: Lo= cal MAC sequence number assignment method listed in this section is intended= to synchronize the sequence numbers between multi-homing PEs that share the= ESI if the local MAC sequence number is less than what is received from the other PE. It is not intended to incr= ement the sequence number beyond what is received from the other PE. I have e= laborated the text for this in this section to make this clearer. 

 

* sectio= n 6.6: How would an implementation detect that the remote implementation doe= s not support the behavior? Could that be explicit explained in the text?

 

[NM]:&nb= sp; Corrected. This section is essentially a specification on how a remote M= AC sequence number must be interpreted if different sequence numbers are rec= eived for MAC and MAC-IP from the same remote PE. Implementing this specification ensures that the PE will be able= to interoperate with another PE that does not synchronize sequence numbers b= etween MAC and MAC-IP (using inheritance). It does not require any explicit k= nowledge of the remote PE being compliant or non-compliant or for this logic to be conditional based on rem= ote PE=E2=80=99s compliance. I have updated the text to be clearer in this r= egard.=

 

* sectio= n 6.7: THis section i did not understand. Too many moving parts. Can this be= explained more explicit or elaborative?

 

[NM]: Co= rrected. updated the section to explain the scenario and remediation better.=

 

* sectio= n 6.8: What network figure is referenced towards?

 

[NM]: Th= ere is no figure attached to this section. PE1 and PE2 are used as two examp= le PEs in the network to illustrate the mobility convergence scenarios in th= is section. I have updated the section to say this.=

 

909 = ;           hosts advertised vi= a NA messages with 0-bit=3D0.  Please refer to

910 = ;           [RFC9161].

 

[major]<= /span>

* Unsure= what purpose of 0-bit=3D0 is and where it is explained in RFC9161. Some exp= licit reference and explanation could help the draft 

 

[NM]: Co= rrected. This is a good catch. There was a typo in the draft (should be O bi= t / flag and not 0-bit). This refers to Override flag in NA messages.  R= eference in this draft is essentially to maintain the behavior defined in RFC 9161, which is to not apply EVPN mo= bility and duplicate address detection procedures to anycast IPv6 hosts lear= nt via NA with O flag set to 0. I have fixed the typo in the draft to explic= itly refer to Override Flag (O Flag) so it can be clearly mapped to handling specified in RFC 9161.=

 

1083&nbs= p;        need for a route clearing CLI for re= covery from duplicate / frozen

1084&nbs= p;        state is truly optional.

 

[major]<= /span>

* what i= s the 0-bit=3D0? please add a specific reference

 

[NM]: co= rrected. Same as above.<= o:p>

&nb= sp;

&nb= sp;

Please d= o let me know if we need to revisit any of the comments above or anything ne= w comes up.

&nb= sp;

Thanks,<= /span>

Neeraj=  =

= --Apple-Mail-9DC28270-A9FC-4212-988B-2F65486538AE--