Re: [mpls] Poll for adoption for draft-vainshtein-mpls-gal-tc-ttl-handling-03

[Stewart Bryant <[e-mail]>]

I have some concerns at the adoption of this draft.

The text:

    When this LSE becomes the top entry in the label stack (because the
    previous label has been popped) some receiving implementations have
    attempted to interpret the fields and this has resulted in errors,
    packet drops, or poor performance.  In particular, packets with an
    LSE with TTL set to zero have been dropped as "expired" while those
    with TTL set to one can be trapped to the generic (slow) MPLS
    exception handler with appropriate rate limiting before the GAL is
    noticed (which would otherwise result in trapping the packet to a
    fast OAM handler).  This document clarifies the rules for setting and
    processing them in the Label Stack Entry that includes the GAL.


Indicates that some implementations have bugs, and we don't normally
publish RFCs to fix bugs. Any system that behaves as above is not
complying with the base MPLS specifications, thus if we feel the need
to publish an RFC as a reminder we should publish it for the general case.
For example what do these implementations do if they see an entropy
SPL, or a extended label SPL?

Thus I think we should reject this draft, and craft a draft that fixed the
problem in general with the GAL used as an example.

As for the change in TTL value, the TTL value was discussed at the time.

I am not sure whether the number should be high or low. Low was I think
chosen in case some buggy implementation actually tried to forward the
packet on the GAL. High is usually chosen so you can tell that the packet
was forwarded and not sent direct, but that label is never supposed to be
forwarded so the problem should never arise.

Thus I am not sure if the original text really needs to change since a 
correctly
implemented system will exhibit the correct behaviour.

- Stewart