[bess] Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-bgp-vpls-control-flags-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/



--
COMMENT:
--

Thanks for this document; it's good to get this behavior clarified and made
more usable.

Unfortunately, I cannot agree with the "no new security considerations"
statement in Section 7.  I wavered for a while on whether to make this a
DISCUSS-level point, but decided not to since I don't think the material
consequences are especially severe.  Please take it under consideration,
though.

It seems to me that we are changing the expected tradeoff
between availability and functionality, and that change should be
documented as a new consideration.  Specifically, the state prior to
this document (in practice) seems to be that when a PE advertises the
C-bit in its NLRI, all PWs in both directions that use that NLRI will
use the CW, or will fail.  Any transient error, random bit flip,
attacker-induced bit flip, etc., would cause a PW failure which is
presumably highly visible.  Using the recommendations in this document,
we prioritize availability over using the CW feature, so those
errors/bit-flips now cause the PW to be established but not use the CW,
which may be a less visible event and have second-order effects for the
traffic therein.  The operator deploying this technology should make an
informed decision about its usage.

(We are also changing the behavior of the S bit so there would be
some considerations there, too, though failure to agree on the S bit
still results in a highly visible outage, so the considerations are a
little different.)

Some other, more minor, section-by-section comments follow.

Section 1

["PE" is not listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and thus would
normally be a candidate for expansion on first use]

   The use of the Control Word (CW) helps prevent mis-ordering of IPv4
   or IPv6 Psuedo-Wire (PW) traffic over Equal Cost Multi-Path (ECMP)
   paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes
   the format for CW that may be used over Point-to-Point PWs and over a
   VPLS. Along with [RFC3985], the document also describes sequence
   number usage for VPLS frames.

RFC 4385 seems to be carrying fairly generic disucssion, to me, without
a clear statement that that CW format should be used for p2p PWs and
VPLS usage.  (Though, I cannot dispute the "that may be used" statement,
since the intent of 4385 seems to be quite generic.)  Perhaps it is more
accurate to say "a format" than "the format", though, absent some other
specification that mandates this particular one?

Section 3.1

This new behavior means that any fault (or attacker influence) causes
the PW to degrade to not using the CW, and possibly to do so "silently".
In other contexts this sort of fallback would get harsh review from the
security community, though it's unclear that the risk/reward here merits
a harsh response.

Section 3.2

   send outgoing frames with sequence numbers as well.  This memo
   further specifies the expected behavior. [...]

I would prefer to see an explicit statement of the semantics of (not)
setting the S-bit, as given by this specification.  (That is, the
previous section says "If a PE sets the C-bit in its NLRI, [...]" but we
don't have a similarly declarative statement for the S bit.)
Note, however, that this is the non-blocking COMMENT portion of the
ballot and I am not trying to impose my preference on you.

Do we need to say that if both PEs send a S-bit of 0, sequence numbers
MUST NOT be used?

I a little bit expected to see some text about why CW usage and
sequencing are sufficiently different so as to get differential
treatment for mismatched advertisement, but perhaps it is not really
necessary for a document of this nature.

Section 5

[VPLS-MULTIHOMING] is not yet in IESG processing; would it make sense to
move this content into that document?

Section 5.2

 The PW behavior is similar to the CW scenario so that the insertion
 of S-bit evaluation SHOULD be independent per PW.  However, because

nit: I think this would be a lot clearer if it was "The PW behavior with
respect to sequencing is similar to the CW scenario".  (But maybe that's
just because my brain is still parsing PW and CW as visually similar and
trying to make them be semantically similar, even though they are not.)

 one PW 

Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

[Muthu Arul Mozhi Perumal]

Hi Jorge,

Okay, thanks for the clarification..

Regards,
Muthu

On Tue, Apr 9, 2019 at 11:17 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Hi,
>
>
>
> I think the definition of Ethernet Tag in the framework draft should be
> clear enough.
>
> There are implementations using configured IDs.
>
> Jorge
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Tuesday, April 9, 2019 at 2:54 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *Jaikumar Somasundaram , "
> bess@ietf.org" , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *Re: [bess] DF election rule in EVPN MH, for untagged interface
> - reg
>
>
>
> Hi Jorge,
>
>
>
> For EVPN VPWS, I understand that service instance identifies are used as
> Ethernet Tags in the DF election. However, for EVPN VPLS is it common to
> configure anything other than the VLAN ID (VID) as the Ethernet Tag? Do we
> have vendor implementations providing such an Ethernet Tag configuration
> different from the VID for EVPN VPLS?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Apr 5, 2019 at 9:49 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> The Ethernet Tag that you use for DF Election does not even need to match
> what you have in the data path.
>
> Note that the definition says even “configured IDs”.
>
>
>
> As long as you use the same ID for the BD on all the PEs attached to the
> ES, you are fine.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Friday, April 5, 2019 at 5:10 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *Jaikumar Somasundaram , "
> bess@ietf.org" , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *Re: [bess] DF election rule in EVPN MH, for untagged interface
> - reg
>
>
>
> Thanks, Jorge. It is clear that the Ethernet Tag needs to be different
> from 0 for the purpose of DF election..
>
>
>
> One of the options a provider has for supporting untagged frames in EVPN
> VPLS multihoming in VID translation...a rule to match untagged frames and
> impose a VID at the ingress and another rule to match that VID and dispose
> it at the egress.
>
>
>
> Are there any other options that can interop well?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Apr 5, 2019 at 11:11 AM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> Hi,
>
>
>
> I think you should check out
> https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09
>
>
>
> This draft updates RFC7432 in certain aspects of the DF Election, and it
> is already at the RFC editor.
>
>
>
> Check out the use of Ethernet Tag in the document.
>
>
>
>o Ethernet Tag - used to represent a Broadcast Domain that is
>
>  configured on a given ES for the purpose of DF election. Note that
>
>  any of the following may be used to represent a Broadcast Domain:
>
>  VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network
>
>  Identifiers), normalized VID, I-SIDs (Service Instance
>
>  Identifiers), etc., as long as the representation of the broadcast
>
>  domains is configured consistently across the multi-homed PEs
>
>  attached to that ES. The Ethernet Tag value MUST be different from
>
>  zero.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *BESS  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Friday, April 5, 2019 at 6:15 AM
> *To: *"bess@ietf.org" 
> *Cc: *P Muthu Arul Mozhi 
> *Subject: *[bess] DF election rule in EVPN MH, for untagged interface -
> reg
>
>
>
> Hi All,
>
>
>
> RFC7432, section 8.5, talks about DF election algorithm (service carving
> algorithm)
>
> only for  for VLAN-based service or  for 
> VLAN-(aware)
>
> bundle service.
>
>
>
> But there wont be any vlan id for untagged interface and so I wonder
>
> how the service carving algorithm can be applied to elect the DF.
>
> Also, should I use the lower VLAN ID even in the case of VLAN-bundle
>
> service, for electing the DF?
>
>
>
> Could some one help me to understand this please?
>
>
>
> =
> 8.5 .  Designated
> Forwarder Election
>
> …
>
>The default procedure for DF election at the granularity of 
>VLAN> for VLAN-based service or  for VLAN-(aware)
>
>bundle service is referred to as "service carving".
>
> …
>
>   Assuming a redundancy group of N PE nodes, for VLAN-based service,
>
>   the PE with ordinal i is the DF for an  when (V mod N)
>
>   = i.  In the case of VLAN-(aware) bundle service, then the
>
>   numerically lowest VLAN value in that bundle on that ES MUST be
>
>   used in the modulo function.
>
> …
>
> ===
>
>
>
> Thanks & Regards
>
> Jaikumar S
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>