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

From: Ross Callon <[email-masked]>
Date: Tue, 6 Oct 2015 19:34:08 +0000

This is to start a two week poll on adopting draft-vainshtein-mpls-gal-tc-ttl-handling-03
as an MPLS working group document.

Please send your comments (support/not support) to the mpls working group
mailing list ([email-masked]<mailto:[email-masked]>).

There are no IPR disclosures pertaining to the draft. The authors have all indicated that
they are not aware of any IPR that applies to this document.

This poll for adoption will end Wednesday October 21, 2015.

Thanks, Ross

---

From: Ross Callon <[email-masked]>
Date: Tue, 6 Oct 2015 19:38:25 +0000

By the way, when I go to the tools web site (tools.ietf.org) I only find the -02 and earlier versions of this draft. The correct -03 version can be found on the datatracker, at:
https://datatracker.ietf.org/doc/draft-vainshtein-mpls-gal-tc-ttl-handling/

Ross

From: Ross Callon [mailto:[email-masked]]
Sent: Tuesday, October 06, 2015 3:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: Poll for adoption for draft-vainshtein-mpls-gal-tc-ttl-handling-03

Thanks, Ross

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 7 Oct 2015 08:40:49 +0100

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

---

From: Matthew Bocci <[email-masked]>
Date: Wed, 7 Oct 2015 11:46:58 +0100

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:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Ross Callon <[email-masked]>
Date: Fri, 23 Oct 2015 15:10:10 +0000

This poll has closed, and we do not have consensus at the current time.

The authors of draft-vainshtein-mpls-gal-tc-ttl-handling and of RFC 5586 are currently
trying to work out a time to meet and resolve their issues. We will make sure that the
MPLS working group is kept up to date on any progress.

Thanks, Ross

Thanks, Ross