Subject: Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Jun 2015 08:47:17 +0100

Thanks.
Typo is fixed in our master XML.

Adrian

> -----Original Message-----
> From: Dongjie (Jimmy) [mailto:[email-masked]]
> Sent: 01 June 2015 03:59
> To: [email-masked]; [email-masked]
> Cc: 'Loa Andersson'
> Subject: RE: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
> 
> Hi authors,
> 
> I think this draft is useful and makes things clear.
> 
> One minor nit in section 3.3:
> s/apply equally all possible uses/apply equally to all possible uses
> 
> Best regards,
> Jie
> 
> > -----Original Message-----
> > From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
> > Sent: Wednesday, May 27, 2015 12:44 AM
> > To: [email-masked]
> > Cc: 'Loa Andersson'
> > Subject: [mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
> >
> > Hi,
> >
> > Sasha, Loa, and I put together a short draft to clarify behavior wrt the TTL
and
> > TC fields of the label stack entry that contains the GAL.
> >
> > Nothing dramatic, just tightening things up for a few issues reported to us
from
> > implementation/interop/field.
> >
> > Review and comments actively sought.
> >
> > Adrian
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: 26 May 2015 17:37
> > > To: Loa Andersson; Alexander Vainshtein; Adrian Farrel; Adrian Farrel;
> > > Sasha Vainshtein; Loa Andersson
> > > Subject: New Version Notification for
> > > draft-vainshtein-mpls-gal-tc-ttl-handling-
> > > 00.txt
> > >
> > >
> > > A new version of I-D, draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
> > > has been successfully submitted by Adrian Farrel and posted to the
> > > IETF repository.
> > >
> > > Name:		draft-vainshtein-mpls-gal-tc-ttl-handling
> > > Revision:	00
> > > Title:		Handling the TC and TTL fields in a Label Stack Entry
when
> the
> > > Generic Associated Channel Label is Present
> > > Document date:	2015-05-26
> > > Group:		Individual Submission
> > > Pages:		6
> > > URL:
> > https://www.ietf.org/internet-drafts/draft-vainshtein-mpls-gal-tc-ttl-
> > > handling-00.txt
> > > Status:
> > https://datatracker.ietf.org/doc/draft-vainshtein-mpls-gal-tc-ttl-
> > > handling/
> > > Htmlized:
> > https://tools.ietf.org/html/draft-vainshtein-mpls-gal-tc-ttl-handling-
> > > 00
> > >
> > >
> > > Abstract:
> > >    This document clarifies handling of the Traffic Class (TC) and Time-
> > >    to-Live (TTL) fields of a Label Stack Entry that contains the Generic
> > >    Associated Channel (G-ACh) Label (GAL).  These clarifications are
> > >    intended to aid interoperability of implementations.
> > >
> > >    Original handling was defined in RFC 5586, and this document updates
> > >    that RFC.
> > >
> > >
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
tools.ietf.org.
> > >
> > > The IETF Secretariat
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Thu, 25 Jun 2015 15:51:08 +0000

Sasha, Adrian -

In the abstract this document claims to "clarify" RFC5586.  However it
actually modifies the behavior in two ways.

First in section 4.2.1.1, RFC5586 states:

  The TTL field of the GAL LSE MUST be set to at least 1.

This can equally be stated as "MUST NOT set the TTL to 0.  However this
document changes that to "SHOULD NOT".  I see absolutely no reason for
this change.

Second, as per 5586 a receiver that discarded a received GAL with TTL=0
was not out of compliance with that rfc.  Now you say that a receiver that
a receiver "that examines an LSE that contains the GAL MUST ignore the
value of the TTL field".

So a piece of hardware, say an ASIC, was designed years ago to discard
packets with a TTL of 0 in the top label is now out of compliance whereas
in RFC5586 the fault in this situation would lie clearly with the sender.

Now suppose further that our ASIC is also programmed to put packets with a
TTL of 1 in the top label on the slow path.  Here the ASIC is not ignoring
the TTL value - it is making a decision based on it.  It is, however,
still enabling a CP or RP to process the GAL.  This, of course, may not be
optimal, but it should not be illegal.
 
So how about we say that "the LER that originates the G-ACh packet SHOULD
   NOT set this value to 1 and MUST NOT set this value to 0."

For the receiver, I think it suffices to say "SHOULD ignore the value of
the TTL field".  But if you want to work a MUST into the language - its
scope should not include the value 0 and the language should not be about
"examining".

Something like "MUST not discard Š based on a TTL value of 1 or more."

George