[bess] Re: Genart last call review of draft-ietf-bess-evpn-fast-df-recovery-09

[Luc André Burdet <[e-mail]>]

Hi Elwyn,

Thanks for the review.  I am updating inline for all comments in -10.

Regarding the ‘major’ below, I am trying to word it better. In fact what happens is that both PEs perform “DF Election” which will inevitable result in some VLANS going DF->NDF and some going NDF->DF – this occurs at both PEs
The idea is that a recovering PE is already in NDF state (it used to be failed/down/ndf) so the DF->NDF transition is somewhat implied and both NDF-DF and DF-NDF happen at t=103 at the newly-inseerted PE.
Because se want to eliminate duplicate traffic, the old-PE will transition the VLANs which are meant to be NDF first thus ensuring an overlap of both sides being NDF for some time.
Let me see If I can reword to be more consistent and better capture.

The Era concern and wording is being rewritten : the intent here is really for that to be out of scope since really it’s a 3-seconds problem in 2036.  The new text reflects to just assume “current” Era same as local.

For the rest of the comments below, I am just updating the document inline for -10

Thanks for the review !

Regards,
Luc André

Luc André Burdet |  Cisco  |  [e-mail]  |  Tel: [phone]


From: Elwyn Davies via Datatracker <[e-mail]>
Date: Monday, August 12, 2024 at 17:56
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [bess] Genart last call review of draft-ietf-bess-evpn-fast-df-recovery-09
Reviewer: Elwyn Davies
Review result: Not 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

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-bess-evpn-fast-df-recovery-09
Reviewer: Elwyn Davies
Review Date: 2024-08-12
IETF LC End Date: 2024-07-31
IESG Telechat date: 2024-08-22

Summary:I apologise for the rather late delivery of this review.  This was
partly due to domestic duties (it was our family birthday/anniversary period
which diverted me from reviewing) and also due to my taking some time to come
to grips with the document.  I am not an expert in the EVPN technology
althoughin essence this is not complex but it took me some time to get a handle
on the technology  which this document is trying to improve. Be that as it may,
there appear to be some areas where the document is not internally consistent
(see the Major Issue) and I think the reliance on what is an extended example
(s3) to explain the operation of the technique has lead to a less than robust
explanation of the generic system, particularly the conflation of the values of
the SCT offset from the time when local recovery is complete and the time delay
used to await the arrival of additional RT-4 messages from other PEs.  These
should be separate parameters in my opinion, and conflating them could lead to
the skew offset resulting in operations being scheduled before the end of the
time delay period.

Major Issues:

s2 vs s3:  If I read the text correctly, the last two paragraphs of s2 appear
to imply that the newly inserted PE performs its service carving (just some
transition to DF state) at the advertised SCT whereas the partner PEs make all
their transitions DF->NDF and NDF->DF  at SCT+skew  (where skew is negative).
However the latter part of s3 appears to imply that the partner PEs only make
their DF->NDF transitions at SCT+skew and both the inserted and partner PEs
make their NDF->DF transitions at SCT.  This seems to be inconsistent.

Minor issues:

s2 and s3: Appropriate choice of SCT:  The SCT is an absolute time.  It is
passed to the other PEs which then have to calculate another absolute time
which is 'skew' earlier than the SCT value at which time the other PEs are
intended to take action..  Thus at the very worst the SCT needs to be 'skew' in
the future at the time it is transmitted to the other PEs so that this time of
action is not in the past.   I think  there needs to be a discussion of the
calculation of the SCT to avoid the other PEs being requested to take action at
a time which has now passed or before they might have received all RT-4s.  The
discussion in s3 conflates the offset of the SCT with the Timer period for
awaiting other RT-4 receptions. I think this means that SCT+skew is before the
expiry of the Timer.

s2.1. para 3:  Improving NTP Era handling:  The need to worry about the NTP Era
seems unfortunate.  If it was assumed that the current NTP Era applied to all
SCT values, only values of SCT less than the value of 'skew' would cause issues
as the time value is used here.  Constraining SCT to be greater than 'skew' is
not an enormous computational burden and the chances are that postponing the
restart of a PE device by one 'skew' if it was lucky enough to need to restart
within one 'skew' of the era changeover are unlikely to be problematic.

Nits/editorial comments:

Global: s/i.e./i.e.,/ (2 instances)

Global: s/BGP Extended Community/BGP EVPN Extended Community/

Abstract, para 1:  Provide a note of RFC  7432 as the basic RFC for the EVPN
solution and flag RFC 8584 when HRW is first mentioned.  Also s/[RFC8584]/(RFC
8584)/ as references are not allowed in the Abstract.

Abstract, para 1: s/Highest Random/the Highest Random/,  s/of the failed
link/of a failed link/

Abstract and s1, para 2: These paras mention 'signalling between the recovered
node' but the previous words refer to recovered node or link.  If it  is a link
that is recovered, which node is involved or how else is the recovery improved?

Abstract and s1, para 1: The terms 'becoming pervasive' and 'next generation'
are not future proof.   Suggest s/becoming pervasive/extensively used/ and omit
'next generation'.

s1, para 2:s/Frowarder/Forwarder/

s1.3, para 1:  The term 'Layer2 duplicate' is used.  Since we are dealing with
an Ethernet infrastructure by definition, presumably this means a duplicated
Ethernet packet.  Can this term be used?  Otherwise this needs some explanation.

s1.3, para 2: The term 'redundancy group' appears in bullet point 3 of Section
8.5 of RFC7432 without precise definition. According to the Cisco EVPN deatures
for the IOS XR Release 7.6
(https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/vpn/76x/b-l2vpn-cg-ncs5500-76x/evpn-features.html)
Redundancy Group membership is configured during startup.  I think this term
might merit some more specific explanation in this document (or an erratum
registered for RFC7432).

s1.3, para 2, 2nd sentence and para 3:

Under certain conditions, this may cause Layer2 duplicates and
   potential loops if there is a momentary overlap in forwarding roles
   between two or more PE devices, consequently leading to broadcast
   storms.

Where can one see evidence for this statement and identification of the
conditions that lead to these problems?  I think this may be covered by the
initial part of s3.  In which case a pointer to this would be helpful.

I am not sure if s1.3,para 3 refers to another difficulty or is a duplication.
Please clarify and again provide evidence and identification of the conditions.

Also the last segment of s1.3 repeats a description of the nature of the
problem described in para 2.

I think the section needs tightening up to give a single description of the
symptoms and possibly give pointer to where problem has been identified and
quantified.

s1.2:  Additional terms need to be defined: NDF, SCT (usefully included in the
terminology sctin).

s1.3, para 5 : s/HRW also cannot help/HRW cannot help either/

s1.4, para 1: s/presents multiples advantages/offers multiple advantages/

s1.4, bullet 2: I cannot parse:    by ensuring that PEs any unrecognized new
BGP Extended Community.

s1.4, bullet 4: suggest
OLD:
(Route Type 4)
NEW:
(Route Type 4;  See [RFC7432] Sections 7 and 7.4)
END

s1.4, bullet 5: "....and normalizes to NTP for EVPN signalling only."  I don't
think 'normalizes' is the right term here.  Do you mean defaults?  Maybe I will
see when I read further on.

s2, para 3:
OLD:
 A new BGP Extended Community, the Service Carving Timestamp
NEW:
IANA has allocated a new sub-type for the BGP EVPN Extended Community (type
0x06) [RFC7153], defining a community of PEs that utilize the time
synchronization recovery mechanism. The "Service Carving Timestamp" with
sub-type value 0x0F (see Section 6) is used in communicating the Serving
Carving Time (SCT) for each Ethernet Segment route (RT-4) to other partners to
ensure an orderly start up or transfer of forwarding duties. END

s2, para 3: It may be obvious but I think it needs to be emphasised that the
skew value must be consistent across all the PEs.  I assume that the intention
is that the skew value should be administratively configurable in PEs
supporting RT-4.  Should there be some advice on range of sensible values?

s2. para 3: The term RT-4 needs to be expanded on  first use (or better RT-4
and SCT should be expanded in the terminology section).

s2.1, paras 1 and 2:  These paragraphs largely duplicate the definition of the
Service Carving Timestamp in s2.  I suggest they are replaced with: The BGP
advertisement of each Ethernet Segment route (RT-4) where this scheme is to be
used contains an EVPN Extended Community (type 0x06) with Service Carving
Timestamp sub-type (Type 0x0F). The expected Service Carving Time is encoded as
an 8-octet value as follows:

s3.1, para 3: s/the 64-bit NTP Timestamp Format/ an adapted form of the 64-bit
NTP Timestamp Format/

s2.1, para 7:
OLD:
    The use of a 16-bit fractional
   seconds yields adequate precision of 15 microseconds (2^-16 s).
NEW:
   The use of a 16-bit fractional
   seconds value yields adequate precision of approximately 15 microseconds
   (2^-16 s).

s2.1, para 8:  Note that the short naming of the flags as 'A' and 'T' is purely
local to this document.  The IANA registry does not register this naming
although 'A'  is used in the same way in RFC 8584.  I suggest OLD:
   This document introduces a new flag called "T" (for Time
   Synchronization) to the bitmap field of the DF Election Extended
   Community defined in [RFC8584].
NEW:
   This document introduces a new flag called Time
   Synchronization ) indicated by "T" in the bitmap field of the DF Election
   Extended Community defined in [RFC8584] (see Figure 3).
END

s3.1/s4:  What should happen if a PE with SCT capability is in process of
recovering and a PE without SCT  capability that was not previously in the
redundancy group  starts recovery?  Doubtless a very rare occurrence but might
occur. for example, if a hardware replacement happened.

s6:  This section needs to be redrafted in more conventional IANA
Considerations format.  There should not be a date column.  It would be helpful
to have references to the IANA registries in the Normatiive Refs.



_______________________________________________
BESS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]