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

[<[e-mail]>]

> " 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 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.

[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:[e-mail]] 
Sent: Wednesday, July 04, 2018 19:24
To: LITKOWSKI Stephane OBS/OINIS
Cc: Stewart Bryant; The IESG; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

On Wed, Jul 04, 2018 at 11:52:53AM +0000, [e-mail] wrote:
> 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.

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 fall into trouble (EL inserted in a non readable position...).

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

> " 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 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

_________________________________________________________________________________________________________________________

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.