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

Greg & Tony

+1

I am completely in agreement with your findings.

Kind Regards

Gyan
On Thu, Mar 31, 2022 at 12:01 PM Greg Mirsky <[email protected]> wrote:

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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email protected] <[email protected]>*



*M 301 502-1347*

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