Subject: [sfc] Continue discussion of changes to NSH

From: Greg Mirsky <[email-masked]>
Date: Mon, 6 Feb 2017 09:31:22 -0800

Dear All,
during SFC WG interim meeting support of infinite loop prevention by
introducing TTL field was proposed and discussed. This and other proposals
will change NSH Base Header affecting existing implementations. The
discussion of backward compatibily have started but, as I recal, we haven't
reached any conclusion. I'd like to propose couple changes to Value field:

   - Section 3.2

OLD TEXT

  Version: The version field is used to ensure backward compatibility
   going forward with future NSH updates.  It MUST be set to 0x0 by the
   sender, in this first revision of NSH.  Given the widespread
   implementation of existing hardware that uses the first nibble after
   an MPLS label stack for ECMP decision processing, this document
   reserves version 01 and this value MUST NOT be used in future
   versions of the protocol.  Please see [RFC7325
<https://tools.ietf.org/html/rfc7325>] for further
   discussion of MPLS-related forwarding requirements.

NEW TEXT

  Version: The version field is used to ensure backward compatibility
   going forward with future NSH updates.  It MUST be set to 0x10 by the
   sender, in this revision of NSH.  Given the widespread
   implementation of existing hardware that uses the first nibble after
   an MPLS label stack for ECMP decision processing, this document
   reserves version 0x01 and this value MUST NOT be used in future
   versions of the protocol.  Value of 0x00 is reserved for Experimental

   use in Section 12.2.1. [Please see [RFC7325
<https://tools.ietf.org/html/rfc7325>] for further
   discussion of MPLS-related forwarding requirements.

   - Section 12.2.1

OLD TEXT

   Version 00: This protocol version.  This document.
   Version 01: Reserved.  This document.
   Version 10: Unassigned.
   Version 11: Unassigned.

NEW TEXT

   Version 0x00: Experimental.  This document.
   Version 0x01: Reserved.  This document.
   Version 0x10: This protocol version. This document.
   Version 0x11: Unassigned.

Appreciate your comments, suggestions.

Regards,

Greg

---

From: Dave Dolson <[email-masked]>
Date: Mon, 6 Feb 2017 17:35:51 +0000

Greg,
On the contrary, I understood we had devised a mechanism that would NOT require changing the version number.

The basic idea was that by using the unassigned flags fields, no existing implementations would be reading or changing those fields. So backwards compatibility is achieved by accepting that not all forwarders or SFs would bump the hop count.

I hope we can see this soon in a new version of the draft…

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, February 06, 2017 12:31 PM
To: [email-masked]
Subject: [sfc] Continue discussion of changes to NSH

Dear All,
during SFC WG interim meeting support of infinite loop prevention by introducing TTL field was proposed and discussed. This and other proposals will change NSH Base Header affecting existing implementations. The discussion of backward compatibily have started but, as I recal, we haven't reached any conclusion. I'd like to propose couple changes to Value field:

  *   Section 3.2
OLD TEXT

   versions of the protocol.  Please see [RFC7325<https://tools.ietf.org/html/rfc7325>] for further

NEW TEXT

   use in Section 12.2.1. [Please see [RFC7325<https://tools.ietf.org/html/rfc7325>] for further

·         Section 12.2.1

OLD TEXT

   Version 10: Unassigned.

   Version 11: Unassigned.

NEW TEXT

Regards,

Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 6 Feb 2017 09:40:00 -0800

Hi Dave,
thank you for the clarification. I've missed that part clearly. Let's wait
for the new version and discuss it then. How many bits for TTL field were
considered?

Regards,
Greg

On Mon, Feb 6, 2017 at 9:35 AM, Dave Dolson <[email-masked]> wrote:

> The basic idea was that by using the unassigned flags fields, no existing
> implementations would be reading or changing those fields. So backwards
> compatibility is achieved by accepting that not all forwarders or SFs would
> bump the hop count.
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Monday, February 06, 2017 12:31 PM
> *To:* [email-masked]
> *Subject:* [sfc] Continue discussion of changes to NSH
>
>
>
> Dear All,
>
>    versions of the protocol.  Please see [RFC7325 <https://tools.ietf.org/html/rfc7325>] for further
>
>    use in Section 12.2.1. [Please see [RFC7325 <https://tools.ietf.org/html/rfc7325>] for further
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Feb 2017 12:47:17 -0500

Actually, Jim and I have an action item (on me, probably Wednesday) to 
provide an email to the list discussing the issue and approach.

Regardign the version number, the goal of the approach is to avoid 
needing to change the version number while still preserving 
interoperability (although obviously not full support of the RFC-to-be) 
for existing implementations.

Yours,
Joel

On 2/6/17 12:35 PM, Dave Dolson wrote:
> The basic idea was that by using the unassigned flags fields, no
> existing implementations would be reading or changing those fields. So
> backwards compatibility is achieved by accepting that not all forwarders
> or SFs would bump the hop count.
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> introducing TTL field was proposed and discussed. This and other
> proposals will change NSH Base Header affecting existing
> implementations. The discussion of backward compatibily have started
> but, as I recal, we haven't reached any conclusion. I'd like to propose
> couple changes to Value field:
>
>   * Section 3.2
>
> OLD TEXT
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 6 Feb 2017 14:38:36 -0600

Hi Greg,

> reached any conclusion. I'd like to propose couple changes to Value field:

Sorry but I don't understand this discussion on backward compatibility.
As far as I know SFC is not deployed.
The nsh protocol in

draft-ietf-sfc-nsh-10.txt
has not been standardized, I.e. no RFC yet, no interoperability tests,
no nothing.

Why should the WG spend cycles on a "baby" that has not even born yet :)?

Regards,

Behcet

> Section 3.2
>    versions of the protocol.  Please see [RFC7325] for further
>    use in Section 12.2.1. [Please see [RFC7325] for further
> Section 12.2.1

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Feb 2017 16:13:14 -0500

We as a working group are free to make changes that we need technically. 
  That is even the case after publication of a PS RFC.  It is certainly 
the case before document completion.

At the same time, folks have been implementing our work.  Which is a 
good and highly desirable thing.

So when we make changes, if we can do so in ways that reduce the pain 
for earlier implementors, that is desirable.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Feb 2017 15:16:43 -0000

Yes. Wot Joel sez.

Basically, *if* we can add the function in a way that does not trash existing
early implementations and that supports a mixed deployment, then let's do that. 

We thought in Westford that we had a way to do this. Admittedly it was invented
somewhat on the fly and a couple of people needed to go home to check what this
would do to their code. As Joel says, he and Jim took the action to write up
(down?) what we discussed.

But, I think it is clearly understood that if we can't find a (practical way)
then the early implementers pay the price of early implementation and (probably)
we cycle the version number (similar to Greg's proposal). We would certainly not
be the first protocol to go to RFC with a version number that has incremented.

Adrian

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 06 February 2017 21:13
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [sfc] Continue discussion of changes to NSH
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Feb 2017 11:08:35 -0600

On Mon, Feb 6, 2017 at 3:13 PM, Joel M. Halpern <[email-masked]> wrote:
> That is even the case after publication of a PS RFC.  It is certainly the
> case before document completion.
>
> At the same time, folks have been implementing our work.  Which is a good
> and highly desirable thing.
>
> So when we make changes, if we can do so in ways that reduce the pain for
> earlier implementors, that is desirable.
>

Maybe we should add a warning to the draft for the early implementers
saying that the risk belongs to you and the WG does not take any
responsibility for the early birds.

Regards,

Behcet
>>> proposals

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 7 Feb 2017 18:47:30 +0100

Behcet,

That’s a well-known chance that you take when you implement any draft
rather than the final RFC. However, early implementations are to be
encouraged, since they act as a proof of concept and often point out
improvements that can be made to the published version of the protocol. So
if the WG can easily make changes that are backwards compatible to earily
implementations, that is to be encouraged. However, as Joel pointed out,
that isn’t always possible.

Cheers,
Andy

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Feb 2017 18:51:33 -0000

A bit surprised that we're having this conversation, but anyway how about we
include some text like the following in the NSH draft?

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Adrian

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Feb 2017 14:56:16 -0600

>    material or to cite them other than as "work in progress."

Absolutely.

BTW I agree with Andy.

Regards,

Behcet

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 8 Feb 2017 15:34:01 +0000

+1 on incrementing the version number.
Indeed, it has been discussed on the interim.
FWIW, I believe it is still worth further consideration.

Cheers,
Tal.

From: sfc [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, February 06, 2017 7:31 PM
To: [email-masked]
Subject: [EXT] [sfc] Continue discussion of changes to NSH

External Email
________________________________
Dear All,
during SFC WG interim meeting support of infinite loop prevention by introducing TTL field was proposed and discussed. This and other proposals will change NSH Base Header affecting existing implementations. The discussion of backward compatibily have started but, as I recal, we haven't reached any conclusion. I'd like to propose couple changes to Value field:

  *   Section 3.2
OLD TEXT

NEW TEXT

·         Section 12.2.1

OLD TEXT

   Version 10: Unassigned.

   Version 11: Unassigned.

NEW TEXT

Regards,

Greg

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 8 Feb 2017 15:49:06 +0000

Hi,

>From a strictly formal perspective, it is absolutely right that the WG is allowed to change the document, as it has not been published as an RFC yet.

Having said that, this draft went into WG LC almost a year ago. To some implementers that is an indication that the document is pretty stable.

Specifically, the topic of loop prevention, and whether SFFs need to take part in it, was actually discussed back in 2015 (https://www.ietf.org/mail-archive/web/sfc/current/msg03814.html), and there was no decision back then to add a TTL to the NSH. 

Certainly, it is possible to rethink the topic a year and a half later and to take a different decision. But at the same time we have to work out a solution that is reasonable for pre-standard implementers.

It would be very problematic to send out a message: "do not implement this until there is an RFC number".

My two cents...

Cheers,
Tal.

>From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Tuesday, February 07, 2017 8:52 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [EXT] Re: [sfc] Continue discussion of changes to NSH
>
>External Email
>
>----------------------------------------------------------------------