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