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

[Alexander Vainshtein <[e-mail]>]

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 value to 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]