Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

[John E Drake <[e-mail]>]

The elephant in the room is that new network actions, whether encoded in the EL LSE TTL field and in post-stack ancillary data or in a new bSPL with a mix of in-stack and post-stack data, will require software and/or hardware upgrades.  This is true, regardless of your assertions to the contrary.  I.e., ELI/EL re-use is either a red herring or a blue whale.

Sent from my iPhone

On Apr 1, 2022, at 1:34 PM, [e-mail] wrote:



[External Email. Be cautious of content]

John,

Please see inline [Bruno]



Orange Restricted
From: mpls <[e-mail]> On Behalf Of John E Drake
Sent: Friday, April 1, 2022 2:13 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>; Greg Mirsky <[e-mail]>; Tony Li <[e-mail]>
Cc: mpls <[e-mail]>; detnet WG <[e-mail]>; [e-mail]
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

Wim,

I did a quick check of the current network action proposals and came up with the following list:

Resource partition [HBH, Forwarding]

E2E Loss Measurement [E2E, Network]

E2E OAM (E2E, Network]

HBH OAM [HBH, Network]

No Reroute [HBH, Forwarding]

Flow ID [HBH, Network]

5G Slice ID [E2E, Network]

Traffic Accounting [HBH, Network]

PTP/Bounded Delay [E2E, Forwarding]

L2 Frame Reassembly [E2E, Network]

As far as I can tell, the only network not requiring ancillary data is No Reroute.  Given that Bruno’s proposal doesn’t meaningfully support ancillary data, how much use is it?

[Bruno]
- draft-decraene-mpls-slid-encoded-entropy-label-id has two other examples.
- from an architecture perspective, Indicators can live independently of ancillary data (location)
- again draft-decraene-mpls-slid-encoded-entropy-label-id can be extended to support in-stack data if needed (this has been expressed multiple times) i.e. if post-stack data is found not to be enough.

--Bruno

Yours Irrespectively,

John



Juniper Business Use Only
From: Pals <[e-mail]<mailto:[e-mail]>> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Thursday, March 31, 2022 2:22 PM
To: Greg Mirsky <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>; detnet WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Pals] [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

[External Email. Be cautious of content]

This is my point and this is what I verified on some systems that don’t care about the TTL and hence work as is, because the ambiguity in the RFC.

Now also we mix 2 discussions points in my view. One is backward compatibility and 2nd is leveraging current HW to support the extensions.
For me the 2nd is also very important as this is actually an important characteristic for the speed at which we can adopt solutions. If we can get extensions with the current HW this is a big pro of the proposals out there. This is why I am advocating to adopt Bruno’s draft as it allows to leverage the existing HW assets as is. Of course we need to do a SW upgrade, but this is still faster than swapping HW is most cases.


From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 31 March 2022 at 17:59
To: Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>, detnet WG <[e-mail]<mailto:[e-mail]>>, mpls <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
I agree that the wording in RFC 6790 is open to interpretation. It is quite possible that a more pedantic developer would put a check for the zero value of the EL TTL field "to ensure that it is not used inadvertently for forwarding". Is it possible to check all existing implementations that support ELI/EL? And I'm surprised that the authors of the draft claim precisely the opposite:
   Hence essentially the TTL field of the EL behaves as a reserved field
   which must be set to zero when sent and ignored when received.

Regards,
Greg

On Thu, Mar 31, 2022 at 8:43 AM Tony Li <[e-mail]<mailto:[e-mail]>> wrote:

Gentlebeings,

On Mar 31, 2022, at 8:29 AM, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:

my interpretation of bullet 4 in Section 4.2 RFC 6790 "The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding" leads me to believe that any other than zero value in the EL TTL field is invalid per RFC 6790. Consequently, that packet MUST be dropped. If that is not breaking the existing network, please help me understand what is it.


Normally, we write clauses that describe such fields as “must be transmitted as zero and ignored upon receipt” just to avoid such ambiguity. It is unfortunate that RFC 6790 did not utilize this phrase. As it stands, it has certainly specified that the TTL field must be transmitted as zero. Yes, that implies that any other value is invalid. However, that does not guarantee that implementations will check.  In fact, the Law of Lethargy (people will do the least amount of work possible) suggests that most implementations will not check and will simply ignore the TTL field completely.

However, this is not a guarantee. Any design that attempts to reuse this TTL field does run a non-zero risk of being impacted by designs that do check and reject such entries.

IMHO, this by itself is not a serious risk, but risk evaluation is always subjective.

Designs should always acknowledge and articulate the risks that they undertake. It is then up to the collective wisdom of the group to weigh and evaluate the risks, benefits, and tradeoffs when making a decision.

Regards,
Tony


_________________________________________________________________________________________________________________________

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.