Re: [mpls] 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 <[email protected]> wrote:

>
> Gentlebeings,
>
> On Mar 31, 2022, at 8:29 AM, Greg Mirsky <[email protected]> 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
>
>

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals