Subject: [sfc] SFC with next protocol = "None"

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 Jan 2017 16:23:25 -0000

Hi,

At the interim, Lucy and I took an action to write this draft. It allows you to
send metadata on an SFP without having a data packet to attach it to.

There was some discussion about whether this idea should find its way into the
base NSH draft. I said "no" because of the volume of material, because it is not
a fundamental of NSH, and because we don't want to hold up the publication of
the NSH spec. That said, if the WG wants to fold it in, I won't object.

Please review and comment. We think it is a simple idea and that the document
pretty much says it all.

Thanks,
Adrian

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 22 January 2017 16:17
> To: [email-masked]
> Subject: I-D Action: draft-farrel-sfc-convent-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
>         Title           : Operating the Network Service Header with Next
Protocol "None"
>         Authors         : Adrian Farrel
>                           Lucy Yong
>                           John Drake
> 	Filename        : draft-farrel-sfc-convent-00.txt
> 	Pages           : 8
> 	Date            : 2017-01-22
> 
> Abstract:
>    This document describes the use of the Network Service Header (NSH)
>    in a Service Function Chaining (SFC) overlay network with no payload
>    data and only carrying metadata.  This is achieved by defining a new
>    "next protocol" type value of "None".
> 
>    This document illustrates some of the functions that may be achieved
>    or enhanced by this mechanism, but it does not provide an exhaustive
>    list of use cases, nor is it intended to be definitive about the
>    functions it describes.  It is expected that other documents will
>    describe specific use cases in more detail and will define the
>    protocol mechanics for each use case.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-farrel-sfc-convent-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 23 Jan 2017 10:41:39 -0800

Dear Authors, et. al,
I have some questions, comments to section 5.4:

   - "Since OAM information will be carried in packets that also include
   payload data, that information must be carried in metadata."

I believe that this is not the case for Active OAM per RFC 7799 definition.
And that is diverging from idea of OAM Header for use in Overlay Networks
<https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-01>. I believe
that Active and Hybrid OAM methods will include OAM specific payload. How
such payload identified, in my view, is to be discussed by the WG. OAM
methods that do not alter SFC packet in a way that affects treatment of the
packet by the network, i.e. forwarding, QoS, classification, can be viewed
as passive OAM methods.

   - "Sending OAM separate from (but interleaved with) packets that carry
   payload data may have several advantages including:"

Is this reference to active OAM methods? Indeed, active OAM methods have
advantages comparing to passive and/or hybrid OAM methods but, at the same
time, they have their disadvantages among them:

   - active OAM methods affect the network by adding additional load;
   - active OAM methods usually require additional consideration,
   instrumentation to ensure in-band with the flow being measured, monitored.

I believe that combination of OAM methods, tools that use active, passive
and, perhaps, hybrid OAM methods required to have comprehensive OAM to
effectively detect and localize defects such as Loss of Continuity,
Miss-connection, Severe Quality Degradation.

Regards,

Greg

On Sun, Jan 22, 2017 at 8:23 AM, Adrian Farrel <[email-masked]> wrote:

> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 23 Jan 2017 19:57:15 +0000

Greg,

“Sending OAM separate from (but interleaved with) packets that carry payload data” can’t guarantee that the OAM packets will traverse the same path as the Payload data as there could be many segments of ECMP being used.

Linda

From: sfc [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 2017年1月23日 12:42
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] SFC with next protocol = "None"

Dear Authors, et. al,

  *   "Since OAM information will be carried in packets that also include payload data, that information must be carried in metadata."
I believe that this is not the case for Active OAM per RFC 7799 definition. And that is diverging from idea of OAM Header for use in Overlay Networks<https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-01>. I believe that Active and Hybrid OAM methods will include OAM specific payload. How such payload identified, in my view, is to be discussed by the WG. OAM methods that do not alter SFC packet in a way that affects treatment of the packet by the network, i.e. forwarding, QoS, classification, can be viewed as passive OAM methods.

  *   "Sending OAM separate from (but interleaved with) packets that carry payload data may have several advantages including:"
Is this reference to active OAM methods? Indeed, active OAM methods have advantages comparing to passive and/or hybrid OAM methods but, at the same time, they have their disadvantages among them:

  *   active OAM methods affect the network by adding additional load;
  *   active OAM methods usually require additional consideration, instrumentation to ensure in-band with the flow being measured, monitored.
I believe that combination of OAM methods, tools that use active, passive and, perhaps, hybrid OAM methods required to have comprehensive OAM to effectively detect and localize defects such as Loss of Continuity, Miss-connection, Severe Quality Degradation.

Regards,
Greg

On Sun, Jan 22, 2017 at 8:23 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,
Adrian

> From: I-D-Announce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
directories.
Protocol "None"
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 23 Jan 2017 12:26:59 -0800

Hi Linda,
I think that the proposed statement is not always correct. In fact,
especially in cases when we define new types of encapsulation, there's good
opportunity to ensure that active OAM does follow the monitored data, i.e.
is fate-sharing, even in presence of ECMP environments along e2e path. We
can document what methods should be used, e.g. use Entropy label rather
than derive entropy from the payload in MPLS network, to ensure that active
OAM is in-band.
And, as the first bullet in section 5.4 notes, active OAM may not be
interleaving with data flow when it is used to monitor non-working, e.g.
protection, paths/segments.

Regards,
Greg

On Mon, Jan 23, 2017 at 11:57 AM, Linda Dunbar <[email-masked]>
wrote:

> Greg,
>
>
>
> “Sending OAM separate from (but interleaved with) packets that carry
> payload data” can’t guarantee that the OAM packets will traverse the same
> path as the Payload data as there could be many segments of ECMP being
> used.
>
>
>
> Linda
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* 2017年1月23日 12:42
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [sfc] SFC with next protocol = "None"
>
>
>
> Dear Authors, et. al,
>
> I believe that this is not the case for Active OAM per RFC 7799
> definition. And that is diverging from idea of OAM Header for use in
> Overlay Networks
> <https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-01>. I
> believe that Active and Hybrid OAM methods will include OAM specific
> payload. How such payload identified, in my view, is to be discussed by the
> WG. OAM methods that do not alter SFC packet in a way that affects
> treatment of the packet by the network, i.e. forwarding, QoS,
> classification, can be viewed as passive OAM methods.
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 23 Jan 2017 22:56:29 -0000

Hi Greg,
 
It is not our intention to (re-)open many OAM discussions held elsewhere.
 
Thus, it is not necessary to explain the benefits of embedding OAM in data packets, nor the limitations of sending stand-alone OAM packets.
The text notes that there are advantages to sending stand-alone OAM packets and observes that this mechanism can achieve the function.
 
As to how OAM will be carried in NSH packets we either need to fix the NSH spec or use metadata. This is notwithstanding any work done anywhere else and is particularly important for implementations being done now. It is also important for the processing rules we have discussed about how to handle unknown "next protocol" types.
 
So, and without trying to prejudge any discussions, the following possible mechanisms exist:
 
- Use metadata
- Use next protocol = "OAM"
- Use the O-bit to say that OAM bytes are found at some place in the packet
 
Only using metadata is consistent with the current spec. The other two approaches cause either:
- packets to be dropped by SFs that don't know what the next protocol is (and how to find the real data)
- a road crash because the meaning of the O-bit is not tightly defined.
 
Just to stress: I don't mind which way this goes, but an implementation of the base NSH spec needs to not barf when OAM passes by.
 
Adrian

From: Greg Mirsky [mailto:[email-masked]] 
Sent: 23 January 2017 18:42
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [sfc] SFC with next protocol = "None"
 
Dear Authors, et. al,
I believe that this is not the case for Active OAM per RFC 7799 definition. And that is diverging from idea of OAM Header for use in Overlay Networks <https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-01> . I believe that Active and Hybrid OAM methods will include OAM specific payload. How such payload identified, in my view, is to be discussed by the WG. OAM methods that do not alter SFC packet in a way that affects treatment of the packet by the network, i.e. forwarding, QoS, classification, can be viewed as passive OAM methods.
 
Regards,
Greg

Thanks,
Adrian

directories.
Protocol "None"

---

From: <[email-masked]>
Date: Tue, 24 Jan 2017 14:21:59 +0000

Hi Adrian, 

Thank you for writing the document. 

FWIW, you may find some comments and suggestions to your I-D here: http://tinyurl.com/h67m5ux  

It is tempting to include the "None" value as part of the NSH document itself, but it is perfectly fine to maintain your document on its own because it provides some sample use cases. 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : dimanche 22 janvier 2017 17:23
> À : [email-masked]
> Objet : [sfc] SFC with next protocol = "None"
> 
> Hi,
>