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

Rolf,

Lots of thanks for your comments.

Please see some answers inline below.

Hopefully these answers will be useful.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

-----Original Message-----
From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
Sent: Wednesday, July 22, 2015 11:38 AM
To: George Swallow (swallow); adrian@olddog.co.uk; Alexander Vainshtein; mpls@ietf.org
Cc: 'Loa Andersson'
Subject: RE: 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.

[[Sasha]] Yes they will remain standard.

But I would prefer George's wording because it does not allow 0 which was the case before.

[[Sasha]] This wording is OK with me.

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.

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<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