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 663DEC14CE39; Wed, 16 Oct 2024 13:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=googlemail.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 C85SsHcfNCCk; Wed, 16 Oct 2024 13:35:32 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 7047AC14F6A0; Wed, 16 Oct 2024 13:35:29 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2e2cc47f1d7so168901a91.0; Wed, 16 Oct 2024 13:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1729110929; x=1729715729; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Z8NKmFcboOhv+KK45TS3Ogj2hLBqwtziF7C2CovX4Y0=; b=FT6u1Qh31pTJNJrJ0oLpJUZw0N3W7I2gmVB+ZfXQq5IcGFKKf9PNFcDXArUQlJmbDR QnBuFGbpFNxBDYKRLegvSOAfFdlUp2+kVlIyOD/kf+SAv58wsdJzgfSXaj6H0rDVVrMH SkuQwqXWqvUkdYgaChOlbDwG7wRR10BHT/qwObF5kTNwNhs+PEqVGU51ICvjom3KP6uG uF/FTZsSaAGA9/J7D8xfkqIEFKbF03AM0r28tL87bu537B+RFJGkzmGeIy4ReuKRicjJ nOaV0plQnDDmmZV93lIhDrHFQ3oEUPbZTs7PFT8o+XPaAyGGMK3aKYyd42BPdRGb5y3t fEfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729110929; x=1729715729; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Z8NKmFcboOhv+KK45TS3Ogj2hLBqwtziF7C2CovX4Y0=; b=ViYKa+6RHQ4b9VM3IP+ldHsnIeCcNyTrSdbkI/mtMnzBiaAPhEeVu7FYkalGkoN5dn ET8vRJpLUUnnBX+zaP2t+fbtpBK6vd1hU8QweMD3GPg3MiIHwsBbCI5F0bVargOo3VUy bJZOrMI80s+C1qceQD3CEKsWeUSrp/afT4IShaLXBvlXzVCcE5L0qnLYCgU4HBDx0YOA qDa8qBNnKHCm745HrklyNX/JjvJfW19NGd20eulc7fY6oMdfQke9R7hKBTHGevIprhEv OVr5zJUdBO4oanOXBl1/9j1lFfUE0mrfFqdIfkZ08NFOJF71tvyLvziWSY/1ItxwmP56 yzCg== X-Forwarded-Encrypted: i=1; AJvYcCVYXX4AMmGh2z5o06R8471SxM4tBjnFY039/vnjLlTDmkTefLEqPbizfmVMmyJIUmNN3kTm@ietf.org, AJvYcCVsC/DuURsgmA/vWVPJ1kt6XdQX5Q4qmSG7gsbsnfNJ8DTcGJTrdXSXelRGEq2W2KRJHm8QaegzsDS/@ietf.org, AJvYcCWreWsNVb04+rCH+KjFU/LnZ9SWWXges0o+OwsZatZjJL8hBKEq1CEgwCU/ePx5TW1wJgHcKCknuHNJBq/oe2yAXuIa7wMe1yhgiLODh1LNB0w8vcBKOK9gxyU=@ietf.org X-Gm-Message-State: AOJu0Yw3ArSuYNOwe0JziFTHPeccvjAEmuz6dOhlsxkqLYDJejQJ69RK mtAFyZnNyLUJxCx9CBd4+dUcEqc42RIVWyN0oOXenzJppAkYGBhN+UPplbpgIT8zcrc922FTU8O 81O7Lxcw5Vqh7xSP4JGR1q8Pcovs= X-Google-Smtp-Source: AGHT+IGFdb4pcxqT76j1iJUJ8bm1jv+n/l/cgVDxI3AK169vyrEPN9yAU/b1Ywm4lachxRP/3KnF/mwHBty24xQJUoI= X-Received: by 2002:a17:90b:391:b0:2e2:7f8f:3ad5 with SMTP id 98e67ed59e1d1-2e3dc1d971amr1300696a91.2.1729110928805; Wed, 16 Oct 2024 13:35:28 -0700 (PDT) MIME-Version: 1.0 References: <172410862149.1996878.6308536175300883213@dt-datatracker-6df4c9dcf5-t2x2k> In-Reply-To: From: Ines Robles Date: Wed, 16 Oct 2024 23:34:52 +0300 Message-ID: To: "Luc Andre Burdet (lburdet)" Content-Type: multipart/alternative; boundary="000000000000b0571d06249e02cf" Message-ID-Hash: VBOR3TIPTFKLZ3PEWJEKVGREMTMTXZHJ X-Message-ID-Hash: VBOR3TIPTFKLZ3PEWJEKVGREMTMTXZHJ X-MailFrom: mariainesrobles@googlemail.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: "rtg-dir@ietf.org" , "bess@ietf.org" , "draft-ietf-bess-evpn-fast-df-recovery.all@ietf.org" , "last-call@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_Rtgdir_telechat_review_of_draft-ietf-bess-evpn-fa?= =?utf-8?q?st-df-recovery-09?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000b0571d06249e02cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Luc Andr=C3=A9, Thank you for addressing my comments. I am Ok with version 11. BR, Ines. On Wed, Oct 16, 2024 at 10:09=E2=80=AFPM Luc Andre Burdet (lburdet) < lburdet@cisco.com> wrote: > Hi Ines, > > > > Thanks for your review. I have posted -11, which I hope addresses all you= r > comments below. > > > > Regards, > > Luc Andr=C3=A9 > > > > *Luc Andr=C3=A9 Burdet* | lburdet@cisco.com | Tel: +1 613 254 4814 > > > > > > *From: *Ines Robles via Datatracker > *Date: *Monday, August 19, 2024 at 19:03 > *To: *rtg-dir@ietf.org > *Cc: *bess@ietf.org , > draft-ietf-bess-evpn-fast-df-recovery.all@ietf.org < > draft-ietf-bess-evpn-fast-df-recovery.all@ietf.org>, last-call@ietf.org < > last-call@ietf.org> > *Subject: *Rtgdir telechat review of > draft-ietf-bess-evpn-fast-df-recovery-09 > > Reviewer: Ines Robles > Review result: Not Ready > > Routing Directorate review of draft-ietf-bess-evpn-fast-df-recovery-09 > > Summary: > > The draft proposes enhancements to the DF (Designated Forwarder) election > process in EVPN, particularly to improve recovery times after failures of > Provider Edge (PE) devices. It introduces a mechanism for fast DF recover= y > using clock synchronization between PEs through the concept of Service > Carving > Time (SCT). The draft updates Section 2.1 of RFC8584. > > Please consider the following comments/questions: > > 1- Section 2: What happens if synchronization fails or becomes unstable? > What > happens if time synchronization between PEs fails entirely (e.g., if > NTP/PTP > synchronization breaks down)? What fallback mechanisms exist if clocks ar= e > out > of sync? > > 2- Section 2.2: What about: "Upon receiving a RECV_ES message, the peerin= g > PE's..." --> "Upon receiving a RECV_ES message (indicating a change in th= e > Ethernet Segment), the peering PE's..."? > > 3- What about adding an operational section, following RFC 5706? > > 4- How should the skew value be configured based on network conditions, > such as > varying latencies between PEs? > > 5- Section 5: What constitutes an "unreasonably large" versus a "reasonab= ly > large" SCT? Maybe adding more text on that distinction would prevent > inconsistency in how different vendors handle invalid timestamps. > > 6- What are the security aspects of the uni-directional signaling approac= h? > > 7- How should scenarios be handled where failures (e.g., misconfiguration > of > SCT) occur asymmetrically, such as partial PE failures where certain VLAN= s > or > services are impacted while others are not? > > Thanks for this document. > > Ines. > > --000000000000b0571d06249e02cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Luc Andr=C3=A9,

Thank you for ad= dressing my comments. I am Ok with version 11.

BR,= =C2=A0
Ines.


On Wed, Oct 16, 2024 at 10:09=E2= =80=AFPM Luc Andre Burdet (lburdet) <lburdet@cisco.com> wrote:

Hi Ine= s,

=C2=A0

Thanks= for your review. I have posted -11, which I hope addresses all your commen= ts below.

=C2=A0

Regards,

Luc Andr=C3=A9

=C2=A0

Luc Andr=C3=A9 Burdet=C2=A0 | =C2=A0lburdet@cisco.com=C2=A0 |=C2=A0 Tel:=C2=A0+1 613 254 4814

=C2=A0

=C2=A0

From: Ines Robles via Datat= racker <noreply@ie= tf.org>
Date: Monday, August 19, 2024 at 19:03
To: rtg-dir@ie= tf.org <rtg-di= r@ietf.org>
Cc: bess@ietf.org= <bess@ietf.org>, draft-ietf-bess-evpn-fast-df-recovery.all@ietf.org= <draft-ietf-bess-evpn-fast-df-recovery.all@ietf.org>= ;, last-call@ietf.o= rg <last-cal= l@ietf.org>
Subject: Rtgdir telechat review of draft-ietf-bess-evpn-fast-df-reco= very-09

Reviewer: Ines Robles
Review result: Not Ready

Routing Directorate review of draft-ietf-bess-evpn-fast-df-recovery-09

Summary:

The draft proposes enhancements to the DF (Designated Forwarder) election process in EVPN, particularly to improve recovery times after failures of Provider Edge (PE) devices. It introduces a mechanism for fast DF recovery<= br> using clock synchronization between PEs through the concept of Service Carv= ing
Time (SCT). The draft updates Section 2.1 of RFC8584.

Please consider the following comments/questions:

1- Section 2: What happens if synchronization fails or becomes unstable? Wh= at
happens if time synchronization between PEs fails entirely (e.g., if NTP/PT= P
synchronization breaks down)? What fallback mechanisms exist if clocks are = out
of sync?

2- Section 2.2: What about: "Upon receiving a RECV_ES message, the pee= ring
PE's..." --> "Upon receiving a RECV_ES message (indicating= a change in the
Ethernet Segment), the peering PE's..."?

3- What about adding an operational section, following RFC 5706?

4- How should the skew value be configured based on network conditions, suc= h as
varying latencies between PEs?

5- Section 5: What constitutes an "unreasonably large" versus a &= quot;reasonably
large" SCT? Maybe adding more text on that distinction would prevent inconsistency in how different vendors handle invalid timestamps.

6- What are the security aspects of the uni-directional signaling approach?=

7- How should scenarios be handled where failures (e.g., misconfiguration o= f
SCT) occur asymmetrically, such as partial PE failures where certain VLANs = or
services are impacted while others are not?

Thanks for this document.

Ines.

--000000000000b0571d06249e02cf--