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

Hi,

I think two things are important:

a) implementations that actually set the GAL TTL to 1 remain standards compliant. My reading of the draft says that that is the case. But I would prefer George's wording because it does not allow 0 which was the case before.

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.

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] On Behalf Of George Swallow
> (swallow)
> Sent: Donnerstag, 25. Juni 2015 17:51
> To: adrian@olddog.co.uk; Alexander Vainshtein; 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
> https://www.ietf.org/mailman/listinfo/mpls