Subject: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 02 Jul 2018 08:26:17 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mpls-spring-entropy-label-11: No Record

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-mpls-spring-entropy-label/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting No Objection, but would still like to see some discussion on the first point.

I see the WG decided to change from targetting Informational to Proposed
Standard as triggered by the RtgDir review.  It's still unclear to me that
this is the best choice, though.  Perhaps a better test than "does this use
RFC 2119 language to normatively specify behavior?" is "can we concretely
test if two independent implementations interoperate?", as would be needed
to move to full Internet Standard.  It's unclear that there is any
cooperative interoperability needed here, as opposed to unilateral choices
made by one peer in the context of a broader framework.  (Perhaps a new
thing here is ther presence of multiple ELs in the stack; I don't know.)
This makes me wonder if the contents would be better recast as a BCP (being
the best practice for assigning multiple entropy labels for SPRING
tunnels).

I guess this ship has sailed and probably I should keep quiet about it (and
yet I'm still talking), but if I understand correctly the entropy label is
not exactly providing fresh entropy (in the form of random input) for
load-balancing, but rather making existing entropy more easily accessible.
My worldview is not represented in RFC 6790 at all, though, so the desire
to maintain consistency over time would contraindicate any big changes to
this document.  Perhaps in Section 1 "provide entropy" could be "make
entropy accessible", or similar, but I suspect I'm in the rough here and
the right answer is actually to do nothing.

There's a lot of "how to advertise this value is outside the scope of this
document", but the only guidance or pointer to external work seems to be in
Section 7.2.1; maybe there could be more internal references to that
section when the "out of scope" remarks appear.  Something like a
parenthetical, "(see Section 7.2.1 for potential approaches)", perhaps.

Some section-by-section comments follow (mostly nits).

Section 1

   [...] Using the
   entropy label in the hash keys reduces the need of a deep packet
   inspection in the LSR while keeping a good level of entropy in the
   load balancing.

s/need of a/need for/

Section 2

Does LSR expand to "Label Switch Router" (as is done in this text) or
"Label Switching Router" (what's in the RFC Editor's word list)?

Section 3

Expand SRGB on first use.

Section 4

It's a little jarring to talk of "position 1 (top)" which is (IIUC) the
bottommost label in the Figure 2 depiction.  (I'm sure readers will know
the intent, of course.)

Section 5

   When an external controller is used to program a label stack on a
   particular node, this node MAY advertise its MSD value or a subset of
   its MSD value to the controller.  How this advertisement is done is
   outside the scope of this document.  As the controller does not have
   the knowledge of the entire label stack to be pushed by the node, the
   node may advertise an MSD value which is lower than its actual limit.

A node's MSD is a scalar value, not a set, so "a subset of its MSD value"
makes no sense; presumably it is advertising a value smaller than its
actual MSD value in this case, as is explicitly mentioned in the last
quoted sentence.  Given the apparent duplication, maybe this text could be
trimmed down, something like:

   An external controller can be used to program a label stack on a
   particular node, which requires the node to indicate to the controller
   what MSD value to be used for that node.  How this advertisement is done is
   outside the scope of this document.  As the controller does not have
   the knowledge of the entire label stack to be pushed by the node, the
   node may advertise an MSD value which is lower than its actual limit.

   In the figure 3, an IP packet comes in the MPLS network at PE1.  All

nit: "comes in to" or maybe just "enters"

Not being a routing person, I always have to look up whether a higher
metric means to give that link more or less traffic, but presumably this is
only a problem for me...

Section 6

   Each LSP associated with a binding SID has its own entropy
   label capability.

I'm not sure I understand what this sentence means.  Is it that I can
assign ELs differently for different LSPs, or that the ERLD at each point
step on the path is a function of the LSP, or something else?

Section 7.1.1

IMPORTANT: I'm confused here; we talk about PE1 having a MSD that lets it
introduce two ELI/EL pairs, but the proposed stack only includes one such
pair, despite the text talking about the need to insert a new ELI/EL next
to P6 for its load balancing.

Section 7.2.2.1

Please expand SPT.

Section 7.2.4

   [...] As example, a service provider

nit: As an example

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 2 Jul 2018 19:35:22 +0100

> the right answer is actually to do nothing.

I do not understand the world view comment.

Regarding the latter comment, it depends on your perspective. It 
provides entropy
in the MPLS layer where insufficient entropy otherwise existed. That entropy
is otherwise accessible (see the Ethernet CW draft), but it is expensive in
hardware terms and implementations make mistakes which give operators a 
difficult time.

Providing entropy in the MPLS layer is how most MPLS engineers normally 
think
about this feature. It is not BTW specified how that entropy is derived 
and that
method may vary from packet to packet with the LSR not knowing how to 
find it in the
payload, if indeed, it is all in the payload at all.

I therefore think "provide" is the correct term.

- Stewart

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Jul 2018 15:55:56 -0500

> I do not understand the world view comment.

In my (security-minded) worldview, if we talk about adding or providing
"entropy", this involves adding actual cryptographic randomness into the
system.  The prevailing worldview in RFC 6790 has it that "providing
entropy" means rearranging bits in the packet headers to make some bits
closer to the front of the packet more unpredictable, if you will forgive
the strained analogy.  For the target audience of the document, trying to
talk about the "adding cryptographic randomness" perspective is actively
confusing (I assume), so I don't propose to make changes that increase
confusion.

> payload, if indeed, it is all in the payload at all.

"entropy" is a notoriously sticky concept to nail down.  Before I learned
about shannon entropy and information-theoretical entropy, I learned
thermodynamics and the statistical mechanics model for thermodynamic
entropy.  This (well, and most definitions of entropy) only make sense in
the context of a distribution function, whether a probability distribution
of the thermodynamic state or a potential distribution of bits in packet
headers.  The entropy relates to the various potential configurations and
the numbers of them that are "equivalent" in some sense; a key prerequisite
is to define which configuration variables are being considered.

Taking that to the immediate context, one could ask whether the "entropy"
in question is in the context of the entire packet contents, all packet
headers, just MPLS headers, just the first MSD MPLS headers, just the first
ERLD MPLS headers, etc.  I have implicitly been assuming that we are
talking about all packet headers, in which case the TCP/UDP ports are
already in scope, so hashing those bits and appending the hash output does
not add any unpredictability ("new configurations", in statistical
mechanics speak).

> I therefore think "provide" is the correct term.

If, on the other hand, we're in the first-MSD or first-ERLD mindset, then
yes, the EL is "providing" entropy, since it's making available state
information that was not previously described in the list of possible
configurations.

I hope all the readers will forgive the rather tangential digression.
Thanks for reading this far,

-Benjamin

---

From: <[email-masked]>
Date: Wed, 4 Jul 2018 11:52:53 +0000

Hi Benjamin,

I don't really understand the discussion here about "entropy" or "providing entropy". I can understand that from a security view point you may have a different definition or usage but in the framework of IP/MPLS, we are always using this terminology. Besides of RFC6790, RFC7348 (VXLAN) also talks about "enabling entropy" by using the source port. I think RFC7510 (MPLSoUDP) also talks about it. 
So I do not really what we could change or improve here.

Regarding your comment about the intended status. The document contains definitions that implementation should agree on. If two implementations does not use the same meaning for the ERLD, we may fall into trouble (EL inserted in a non readable position...).

" Section 4

It's a little jarring to talk of "position 1 (top)" which is (IIUC) the bottommost label in the Figure 2 depiction.  (I'm sure readers will know the intent, of course.)
"
[SLI] I like the OSI representation of protocol stacks which puts the lower layer at the bottom, it looks more natural to me. Sorry for that :) I can fix it if necessary.

I will take care about the editorial comments you made in a next revision. Thanks for pointing them.

Brgds,

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2018 22:56
To: Stewart Bryant
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

-Benjamin

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Jul 2018 12:24:08 -0500

> So I do not really what we could change or improve here.

Right, there seems to be different prevailing usage in the community
associated with this document and in the security community.  We probably
can't do much to change that, and certainly not in this document.  My
comment was mostly just intended to raise visibility of the different
usages/communities.  If there was a minor wording tweak that would make it
less confusing to me without changing the meaning, we could do that, but I
don't insist on any change -- the primary audience remains the IP/MPLS
community with its established usage.

> Regarding your comment about the intended status. The document contains definitions that implementation should agree on. If two implementations does not use the same meaning for the ERLD, we may fa…

Right.  But would the trouble be "traffic gets load balanced poorly" or
"traffic gets dropped"?

> [SLI] I like the OSI representation of protocol stacks which puts the lower layer at the bottom, it looks more natural to me. Sorry for that :) I can fix it if necessary.

I don't even know that I could claim that a change would be a "fix" as
opposed to a regression.  I was just pointing out the apparent conflict,
but don't expect any real harm from leaving it as-is.

> I will take care about the editorial comments you made in a next revision. Thanks for pointing them.

Thanks!

-Benjamin

---

From: <[email-masked]>
Date: Thu, 5 Jul 2018 23:06:57 +0000

>but don't expect any real harm from leaving it as-is.

[SLI2] I have added the following comment:
"if it is placed between position 1 (top of the MPLS label stack)". I think "top of the MPLS label stack" is more clear than initial "top" which could refer at the top of the diagram as you mentioned.

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Wednesday, July 04, 2018 19:24
To: LITKOWSKI Stephane OBS/OINIS
Cc: Stewart Bryant; The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

Thanks!

-Benjamin