Re: [mpls] Responding to comments in the WG adoption poll for draft-vainshtein-mpls-gal-tc-ttl-handling

["Bocci, Matthew (Matthew)" <[e-mail]>]

Sasha

Thanks very much for responding in detail. The problem is that the draft does still discuss the case of implementations treating the TTL as if it indicates something about the OAM packet. I’ve discussed this with the co-editors of RFC5586 (Stewart and Martin) and it really seems to us that the draft is motivated by this.

As co-authors of RFC 5586, we are concerned with the impact on existing implementations of trying to update 5586 to work with a specific proprietary implementation. That implementation seems to rely on TTL signalling the OAM priority. This use of TTL is a deviation from the MPLS architecture. It is not clear that this is the right thing to do, but if
there is consensus to make that change it should be up-front rather than a by-product of this document.

However, we do acknowledge that we were not very strict in the specification of the TTL value: must be at least 1, and exact value is application specific. So that has left the door open to people making wrong decisions.

Since there are no known issues with the existing implementations of RFC5586, it seems inappropriate for this new draft to be an update. It
also appears to legitimise the proprietary interpretations and will not solve the problems that they introduce, which are never going to interoperate with
the existing deployed base even with  this draft. This makes the usefulness of the document rather tenuous.

We see no need to publish this document, but if there is consensus that it should be published, then an acceptable way forward would be to make the document an informational and not to update RFC 5586.

Matthew



From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 13 October 2015 at 16:10
To: "Stewart Bryant ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>, Matthew Bocci <[e-mail]<mailto:[e-mail]>>, "Andrew G. Malis ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>
Cc: "'[e-mail]<mailto:'[e-mail]>'" <[e-mail]<mailto:[e-mail]>>, "Loa Andersson ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>, "Ross Callon ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Responding to comments in the WG adoption poll for draft-vainshtein-mpls-gal-tc-ttl-handling

Stewart, Andy, Matthew and all,
I would like to respond to the comments received so far in the adoption poll for draft-vainshtein-mpls-gal-tc-ttl-handling, and I would like to do it in one email.

First of all I’d like to thank Andy for his  support:).

The rest of my mail deals with comments from  Stewart (here<https://www.ietf.org/mail-archive/web/mpls/current/msg14874.html>) and Matthew (here<https://www.ietf.org/mail-archive/web/mpls/current/msg14875.html>). I apologize in advance for a rather long email, but I think that some explanations are required.

One point that I’d like to make is that the text quoted in Stewarts’ comment (and presumably causing his concerns) comes from an earlier (-01) version of the draft but does not exist in the -03 version<https://tools.ietf.org/html/draft-vainshtein-mpls-gal-tc-ttl-handling-03> of the draft (for which adoption has been requested by the authors).
The current text says:

   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 TC and TTL fields.  In particular, packets
   with an LSE that contains the GAL 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).  The resultant poor
   performance in handling TTL of one could be seen as a poor
   implementation choice, but it does not violate RFC 5586<https://tools.ietf.org/html/rfc5586>.

I assume that Stewart’s conclusion “Any system that behaves as above is not complying with the base MPLS specifications” has been correct with regard to the old text (which erroneously mentioned setting TTL in the GAL LSE to 0), but I do not see that implementations described in the new text would violate any base MPLS specifications. Do I miss something?

My next point is about Matthew’s comment that mentions “changing the recommended TTL value to work around a specific implementation”. Actually RFC 5586<https://tools.ietf.org/html/rfc5586> does not recommend any specific TTL valueto be set in the GAL LSE, it just says that this value MUST NOT be set to 0.

Next, when it comes to preventing “buggy implementations forwarding packets when the GAL is exposed” by setting the TTL value to 1 in the GAL LSE: this is definitely worth discussion. From my POV this discussion could be done after adoption, but, at least the draft in its current form does not prevent setting TTL to 1 even if it RECOMMENDS a different default.

Regarding yet another Stewarts’ comment, namely that “that label (Sasha: GAL) is never supposed to be forwarded so the problem (Sasha: which TTL value to set in the GAL LSE) should never arise” – from my POV this is not quite correct. In modern systems packets that are not supposed to be forwarded (for whatever reason) could be processed by not just by SW but also by HW accelerators (e.g., for fast OAM). Failure to differentiate between these two cases would mean that two standard-compliant implementations are de-facto not interoperable. The ultimate objective of the draft is to eliminate (or at least to minimize) the possibility of such conflicts by filling in what I see as gaps in the 5586.

Last but not least, Stewart has asked about behavior of implementations that encounter some other special purpose labels, specially mentioning Entropy Label Indicator (ELI) defined in RFC 6790<https://tools.ietf.org/html/rfc6790> and Extended Special Purpose Label indicator (XL)  defined in RFC 7274<https://tools.ietf.org/html/rfc7274>.
I have checked both these documents, and from my POV RFC 6790 unambiguously defines the behavior related to TC and TTL in LSE containing ELI and EL  in Sections 4.1 and 4.2.
Quoting from Section 4.1 “Egress LSR”:

   When processing the final tunnel termination,

   Y (Sasha: the egress LSR for the tunnel) MAY enqueue the packet based on that tunnel TL's

   or ELI's TC value and MAY use the tunnel TL's or ELI's TTL to compute the

   TTL of the remaining packet header.  The EL's TTL MUST be ignored.

Quoting from Section 4.2 “Ingress LSR”:

       If Y has indicated that it can process ELs for the tunnel,

       push <TL, ELI, EL> onto the packet.

       X (Sasha: the ingress LSR for the tunnel)SHOULD put the same

       TTL and TC fields for the ELI as it does for TL.

       X MAY choose different values for the TTL and TC

       fields if it is known that the ELI will not be exposed as the top

       label at any point along the LSP (as may happen in cases where

       PHP is used and the ELI and EL are not stripped at the

       penultimate hop (see Section 4.4<https://tools.ietf.org/html/rfc6790#section-4.4>).  The BoS bit for the ELI MUST

       be zero (i.e., BoS is not set).  The TTL for the EL MUST be zero

       to ensure that it is not used inadvertently for forwarding.  The

       TC for the EL may be any value.  The BoS bit for the EL depends

       on whether or not there are more labels in the label stack.


RFC 7224 does not explicitly mention how the TTL and/or TC in the LSE containing XL, but it says that “The XL only assigns special meaning to L” (Sasha: the next label in the stack). To me this can only be interpreted as a requirement for the LSR that exposes the XL to ignore TC and TTL values in the corresponding LSE even if 2119 language is not used. So I do not see (at least at this moment) any need in extending the draft for the “general” case, since GAL is the only special purpose label for which handling of TC and TTL fields by the receiver is not clearly defined.

Hopefully these notes would be useful and help to resolve your concerns regarding adoption of the draft.
Of course, once the draft is adopted, the WG could resolve any remaining (or newly identified) issues.

Regards,
Sasha










Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>