Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt

["Adrian Farrel" <[e-mail]>]

Hi George,

Closing the loop on this after several email exchanges.

> In the abstract this document claims to "clarify" RFC5586.  However it
> actually modifies the behavior in two ways.
> 
> First in section 4.2.1.1, RFC5586 states:
> 
>   The TTL field of the GAL LSE MUST be set to at least 1.
> 
> This can equally be stated as "MUST NOT set the TTL to 0.  However this
> document changes that to "SHOULD NOT".  I see absolutely no reason for
> this change.
>
> Second, as per 5586 a receiver that discarded a received GAL with TTL=0
> was not out of compliance with that rfc.  Now you say that a receiver that
> a receiver "that examines an LSE that contains the GAL MUST ignore the
> value of the TTL field".

Compliance and conformance to RFCs has never been something that I have been
enthusiastic about. Especially not being out of compliance by not doing
something.

Our aim here is not to set more rules for measuring compliance, but to increase
the chance of interoperability in the future.

And let's understand that nothing we write can in any way change whether an
implementation is compliant to 5586 since that document is already published.

> So a piece of hardware, say an ASIC, was designed years ago to discard
> packets with a TTL of 0 in the top label is now out of compliance whereas
> in RFC5586 the fault in this situation would lie clearly with the sender.

The fault continues to lie with the sender. However, being able to point a
finger and say "the sender is broken" doesn't really help deployments. The aim
is for new implementations to be allowed to process correctly despite the faults
of the sender.

> Now suppose further that our ASIC is also programmed to put packets with a
> TTL of 1 in the top label on the slow path.  Here the ASIC is not ignoring
> the TTL value - it is making a decision based on it.  It is, however,
> still enabling a CP or RP to process the GAL.  This, of course, may not be
> optimal, but it should not be illegal.

Indeed. Let us hope that Warren's Internet Police do not descend on us!

> So how about we say that "the LER that originates the G-ACh packet SHOULD
>    NOT set this value to 1 and MUST NOT set this value to 0."

You're right about this and we have moved to "MUST NOT 0 and SHOULD NOT 1"

> For the receiver, I think it suffices to say "SHOULD ignore the value of
> the TTL field".  But if you want to work a MUST into the language - its
> scope should not include the value 0 and the language should not be about
> "examining".
> 
> Something like "MUST not discard Š based on a TTL value of 1 or more."

Yes.
"An LER that examines an LSE that contains the GAL SHOULD ignore the value of
the TTL field, and MUST NOT discard the packet based on the value of the TTL
field."

Cheers,
Adrian

PS Response to Rolf's addendum to this thread comes in a separate email.