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

I have similar concerns.

I am not sure we should be changing the recommended TTL value to work 
around a speciifc implementation. I also recall that the value of 1 was 
chosen to prevent buggy implementations forwarding packets when the GAL 
is exposed.

Matthew

On 07/10/2015 08:40, Stewart Bryant wrote:
>
> 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
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls