Re: [mpls] 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>