Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt

Rolf, all,

I want to see whether we can close this point down.

As I understand Rolf's point, some packets may use a TTL of one (usually, but not always by hop-by-hop decrement) to cause the packet to be ejected from the forwarding path and to enable it to be processed as an OAM packet.

I think the point here is that the top label is a normal forwarding label and, if the TTL did not expire, the packet would continue to be forwarded to the destination as usual. Therefore, in order to target an OAM packet at a transit LSR, the TTL is set to a lower number. In fact, knowing the path, one can target an specific LSR along the path, or (by steadily incrementing the value of TTL transmitted) one can trace a path.

In this case, however, it is not the TTL of the LSE containing the GAL that is found to have the value one. Rather it is the TTL of the top LSE (that which contains a normal forwarding label).

So we are left with the question: could the GAL ever be in the top LSE for an incoming packet?

The only possibilities I can think of are:
- when the previous hope did pop-and-go without examining the underlying LSE
- when the packet is being deliberately sent on an MPLS Section (i.e. a single hop)

RFC 5586 doesn't have anything (that I can find) to say about these cases.

In the first case, I am pretty sure that the OAM packet was intended to be processed by the LSR that popped the previous label. However, this doesn't mean that the packet might not "escape" from an LSR that is configured for pop-and-go (such as in a PHP) case. It would, IMHO, represent a broken implementation, but I can believe that implementations pre-dating 5586 might do this.

In the second case, I can see why this might be done, but I worry that the OAM is being applied to an MPLS-capable link and not to a segment of a specific LSP, there being no way to associate the received OAM packet with an LSP without a preceding label.

Furthermore, I don't see how a receiver can disambiguate these two cases without looking deeper into the contents of the packet, and I'm not sure that there is guaranteed to be sufficient information in all packets to allow the receiver to know the difference between:
- this packet "escaped" its intended recipient
and
- this is an "unlabelled" packet meant for me

So I wonder...

Does the WG want to make some statement about an LSE containing the GAL never being valid at the top of the stack? Or have I missed something defined elsewhere?

Thanks,
Adrian

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] 
Sent: 24 July 2015 17:25
To: Rolf Winter
Cc: 'Loa Andersson'; George Swallow (swallow); adrian@olddog.co.uk; mpls@ietf.org
Subject: Re: draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt

Rolf,
I must admit that I have gailed to understand just HOW TTL in the GAL-containing LSE is used for addressing. I am not aware of any RFCs dedcribing this.
Could it posdibly be that you have referred to TTL in the LSE containing a normal label being set to 1 for the Next Hop LSR to trap the OAM packet as part of *segment* (not "*section*) OAM? If so this completely unrelated to the TTL value that us set by the transmitter in the GAL-containing LSE.

As for fixing just the receivers by ignoring received TTL value in the GAL-containing LSE - the draft does that, but it also RECOMMENDS not sending TTL in this LSE to 1 in order to avoid problems with recrivers that comply to 5586 but not to this document.

Hope this helps.

Thumb typed on my LG,
Sasha

------ Original message ------
From: Rolf Winter
Date: 24/07/2015 12:23
To: Alexander Vainshtein;
Cc: 'Loa Andersson';George Swallow (swallow);adrian@olddog.co.uk;mpls@ietf.org;
Subject:RE: draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
See inline [things we agree on snipped]

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

> b) when the GAL is used for section OAM, then setting the TTL to 1 is
> necessary as it is used for addressing.
> 
> This is a noteworthy exception to the rule outlined in the document.
> 
> [[Sasha]] I may be missing something but I do not really understand why
> such an exception is required.
> 
> I assume that by "Section OAM" you refer to the case when the top LSE
> in the label stack contains GAL.
> 
> If this is correct, then this LSE  (being the top one) would be
> examined by the LSR at the other end of the data link, and the packet
> immediately identified as an OAM packet based on the fact that the
> examined LSE contains GAL. Further disposition of this packet would be
> then decided by the packet type as encoded in the GACH and, if
> necessary, buy packet type-specific means. This would happen regardless
> of the TTL value in this LSE. Setting it to 1 should not really change
> anything IMHO.

Well, the TTL is being used here for addressing and you want to change these semantics. Architecturally, this doesn't seem right. If "just look at the label" is a valid fix to the problem, why not fixing the receivers that have the problem. Why changing all the senders?

> 
> 
> 
> Generally, the proposal begs the question "why having all senders
> change when the problem seems to be in some receivers".
> 
> 
> 
> Best,
> 
> 
> 
> Rolf
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West
> End  Road, London, HA4 6QE, GB | Registered in England 2832014
> 
> 
> 
> > -----Original Message-----
> 
> > From: mpls [mailto:mpls-bounces@ietf.org <mailto:mpls-
> bounces@ietf.org> ] On Behalf Of George Swallow
> 
> > (swallow)
> 
> > Sent: Donnerstag, 25. Juni 2015 17:51
> 
> > To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; Alexander
> Vainshtein; mpls@ietf.org <mailto:mpls@ietf.org>
> 
> > Cc: 'Loa Andersson'
> 
> > Subject: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
> 
> >
> 
> > 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
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > _______________________________________________
> 
> > mpls mailing list
> 
> > mpls@ietf.org <mailto:mpls@ietf.org>
> 
> > https://www.ietf.org/mailman/listinfo/mpls
> <https://www.ietf.org/mailman/listinfo/mpls>