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

[Greg Mirsky <[e-mail]>]

Hi John,
indeed, if ELI is at the top of the stack, then it must be removed along
with EL. In my reading of RFC 8662 I did not find a reference to how EL's
TTL is handled. I think that "a SPRING router: MUST be entropy label
capable and, as a consequence, MUST apply the data-plane procedures defined
in [RFC6790]" helps with the imposition of ELI,EL but seems lacks
sufficient clarity in case of the transit SPRING router disposing of
ELI,EL, particularly in regard of EL's TTL handling. WDYT?

Regards,
Greg

On Fri, Apr 1, 2022 at 1:57 PM John E Drake <[e-mail]> wrote:

> Greg,
>
>
>
> I pointed this out on the list last June and Bruno and Sasha basically
> called me a twit.  However, the fact remains that RFC 8662 does not
> describe how to get rid of an ELI/EL that is about to rise to the top of
> stack.
>
>
>
> The correct answer is that the node which will pop the forwarding label at
> the top of stack which will expose the ELI/EL must remove the ELI/EL from
> the stack.  Apparently, this is blindingly obvious to the informed reader.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Pals <[e-mail]> *On Behalf Of * Greg Mirsky
> *Sent:* Friday, April 1, 2022 4:38 PM
> *To:* Bruno Decraene <[e-mail]>
> *Cc:* mpls <[e-mail]>; detnet WG <[e-mail]>; Tony Li <
> [e-mail]>; [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]*
>
>
>
> Hi Bruno,
>
> thank you for pointing me to the text in Section 4.1. I agree that for the
> case described in RFC 6790, i.e., a single ELI, EL in the stack, that text
> sets clear requirements for disposing of ELI,EL. What I wanted to bring to
> the discussion is how a transit node does that in the SR-MPLS scenario (RFC
> 8662
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8662__;!!NEt6yMaO-gk!TlHg2NIqz8tuFJm-BGu4GUaE6em2PA4SyD5ryXBVvckZ8ca_EDq4xk-NA2fzyJ8$>).
> I think that there's no text in RFC 8662 that establishes equivalency
> between a transit node disposing of ELI,EL if ELI is at the top of the
> stack and the LER per RFC 6790. That might cause different interpretations
> resulting in different handling. How practically we can collect information
> about deployed solutions?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Apr 1, 2022 at 9:06 AM <[e-mail]> wrote:
>
> Greg,
>
>
>
> > *From:*  Greg Mirsky
>
> > 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
>
>
>
> RFC 6790 says
>
> « 4.1 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6790*section-4.1__;Iw!!NEt6yMaO-gk!TlHg2NIqz8tuFJm-BGu4GUaE6em2PA4SyD5ryXBVvckZ8ca_EDq4xk-NUbPRgzM$>.  Egress LSR »
>
> […]
>
> “The EL's TTL MUST be ignored.”
>
> https://datatracker.ietf.org/doc/html/rfc6790#section-4.1
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6790*section-4.1__;Iw!!NEt6yMaO-gk!TlHg2NIqz8tuFJm-BGu4GUaE6em2PA4SyD5ryXBVvckZ8ca_EDq4xk-NUbPRgzM$>
>
>
>
>
>
> To me, that does not read like open to interpretation.
>
>
>
> > And I'm surprised that the authors of the draft claim precisely the
> opposite
>
>
>
> Are you now feeling better about the authors?
>
>
>
> --Bruno
>
>
>
>
>
> Orange Restricted
>
> *From:* mpls <[e-mail]> *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, March 31, 2022 6:00 PM
> *To:* 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)
>
>
>
> 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]> wrote:
>
>
>
> Gentlebeings,
>
>
>
> On Mar 31, 2022, at 8:29 AM, Greg Mirsky <[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.
>
>