Subject: [sfc] early AD review of draft-ietf-sfc-nsh-05

From: Alia Atlas <[email-masked]>
Date: Mon, 6 Jun 2016 20:17:58 -0400

I have done an early AD review of draft-ietf-sfc-nsh-05. First, I would
like to thank Paul, Uri, and all the contributors and WG members who have
done so much work on this.

Second, this document still needs a lot of work before it is ready to
advance.  I haven't scrutinized the references for my review - but I would
ask you to think about what should be normative so that someone can
implement NSH.

Major:

a) Sec 3.2:  " O bit: when set to 0x1 indicates that this packet is an
Operations,
   Administration and Maintenance (OAM) message.  The receiving SFF and
   SFs nodes MUST examine the payload and take appropriate action (e.g.
   return status information).  OAM message specifics and handling
   details are outside the scope of this document."

I am quite concerned that this document requires (MUST) conformance to a
document that isn't in any way referenced or specified.  Basically, an
implementer has no way to be compliant.  At a minimum, this should have a
Normative Reference to the OAM procedures.

If truly necessary, another way out would be to reserve this bit for OAM
but save the definition and behavior for the OAM draft.  That'd be
unfortunate in that implementations could conform to NSH but not the
associated OAM.

b) Sec 3.2:  I have three points on the "Next Protocol" field.  First,
please read Section 8 of draft-ietf-rtgwg-dt-encap-01, which discusses the
issue of each encapsulation defining its own Next Protocol field.  Please
take a look at VXLAN-GPE, GUE, GENEVE, and BIER to see which of those "Next
Protocol" fields can merge to be the same registry.  I know that one of
them is currently using EtherType, but at least 1 or 2 others also has an
8-bit "Next Protocol" field.   The name should also be improved to be much
clearer as to what it is, what types of protocols might fit in it, and how
it might be extended or reused.  These obviously apply to Sec 13.2.5 as
well.

c) Sec 3.2: "Service Index (SI): provides location within the SFP. The first
   classifier (i.e. at the boundary of the NSH domain) in the NSH
   Service Function Path, SHOULD set the SI to 255, however the control
   plane MAY configure the initial value of SI as appropriate (i.e.
   taking into account the length of the service function path).
A Classifier
   MUST send the packet to the first SFF in the chain.
   Service index MUST be decremented by service functions or proxy nodes
   after performing required services and the new decremented SI value
   MUST be used in the egress NSH packet.  SI SHOULD be used in
   conjunction with Service Path Identifier for Service Function Path
   selection.  Service Index (SI) is also valuable when troubleshooting/
   reporting service paths.  In addition to indicating the location
   within a Service Function Path, SI can be used for service plane loop
   detection."

  First, there seem to be a number of assumptions in this paragraph about
Classifiers - including that there is only one per service function path
("MUST send the packet to the first SFF in the chain") - despite earlier
discussion of re-classification.   PLEASE - pull out the description of the
field such as:

  "The Service Index provides a location within the SFP.  The index should
strictly decrease from its initial value.  The function that encapsulates
the packet in NSH SHOULD set the SI to 255.  SI MUST be decremented..."

from normative behavior for a Classifier and text describing why the field
is useful.
I am assuming that there are more details around troubleshooting and
service plane loop detection elsewhere?

d) Sec 3.4:  What is the required behavior for parsing the "Mandatory
Context Header" fields?  Can an implementation support just what is in this
document?  Do the documents on allocation also describe the appropriate
parsing?  I see them as informative references.  Can an implementation
ignore the contents of the "Mandatory Context Header" fields?  Without a
normative reference to how this is to be implemented, received, and parsed,
I don't see that this provides implementable and complete behavior.

e) Sec 6:  This section needs work. First, please read sec 9 of
draft-ietf-rtgwg-dt-encap-01 for some ideas.  At a minimum, you need to
clarify what the mandatory behavior is and what the failure conditions or
results are.   For more details:  Jumbo Frames help only when the packet or
frame being encapsulated isn't already at the maximum.  I fully agree that
is likely to the case for much traffic - but it isn't the guaranteed
solution this tries to treat it as.   Sure - it is possible to determine
the Path MTU - but is that to the next SFF or through the entire SFP?  Can
it be the whole SFP when re-classification may change what the desired path
is?  What happens at an SFF if it determines that the Path MTU beyond is
too small?  What are the consequences of fragmenting by the transport?   As
for the third example from RFC6830 - I'm assuming you mean the stateless
case - which basically amounts to determining a Path MTU and then
fragmenting.

The Path MTU approaches don't handle at all the case of adding
context-headers by an SF in the middle of the path.  That can obviously
require fragmenting the packet and then adding NSH headers which is
specifically not expected at the SF or SFF (see Sec 4).

These approaches also assume that it is possible to fragment the data
contained inside the NSH header.  In the case of something like an Ethernet
frame, that isn't the case..

The likely short form is that the network operator sets a different MTU
inside the space for the SFP which can accommodate a given size of header.
The Classifiers and SFF/SFs are set up to send some type of error messages
and log and drop the offending packets or frames if they are too large.  If
the next-protocol type can be fragmented, then there is more functionality
to define/describe.  Regardless, the consequences of unexpected
fragmentation should be clearly articulated and ways of detecting it
discussed.

f) Sec 8.1:  Privacy considerations will matter for information such as VRF
or tenant, depending on how those are expressed and trackable.   Similarly,
the security implications of an SF terminating  encrypted traffic will need
to be articulated.

g) Sec 9:  This section needs to be pulled out into its own draft.  That
draft should describe the considerations associated with carrying NSH.
Regardless, it is not acceptable for the WG to partially and minimally
document the "preferred transports" by providing them as "encapsulation
examples" while pushing strongly back against less-preferred transports
(e.g. the discussions around UDP and MPLS).  The fact that this section has
no words and merely gives self-evident examples - such as Sec 9.3 where an
Ethernet Frame indicates the included type using the EtherType - makes it
look quite strongly as if it is simply providing examples so others can
implement without straying into transport details.

h) I will also note that the suggested EtherType=0x894F is registered with
IEEE as "
This protocol identifies the Cisco vPath Network Service Header protocol
used in inserting and chaining services in the network."   I am checking
with IEEE as to whether they allow changes in the protocol meant;
certainly, IETF managed registries do not due to the interoperability
concerns.  Regardless, there are experimental EtherTypes and after this
document finally has IESG approval, the IEEE will allocate an EtherType for
NSH.

i) The Security Considerations section says nothing about privacy around
metadata.  It refers informationally to
draft-reddy-sfc-nsh-security-req-00, which gives requirements but no
mechanisms.  Obviously, that doesn't adequately address the security
concerns.  The WG Chairs are welcome to request an early Security
Directorate review to see the types and level of issues that will come up.

j) Sec 13.2.4:  First, this requires text describing what rules the DE
should apply.  Second, I would recommend having part of the range be
Specification Required and that a specification is required by the
Designated Experts also.  There probably should be a Private Use section
for companies that need a private section.  Take a read through
https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ to get
full context on what is expected.

Minor:

1) Sec 3.2: Please add an informational reference for the "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."  That could be either RFC 7325 or Section
8 of draft-ietf-rtgwg-dt-encap-01.

2) Sec 3.2:  "All other flag fields are reserved for future use.  Reserved
bits
   MUST be set to zero when sent and MUST be ignored upon receipt."

I think that this is better as "SHOULD be ignored upon receipt" to handle
future
extensions.  I know I've had this conversation several times on different
drafts.

3) Sec 3.5.1: "Metadata Class (MD Class): describes the scope of the "Type"
field.
   In some cases, the MD Class will identify a specific vendor, in
   others, the MD Class will identify specific standards body allocated
   types.  Please see IANA Considerations section below."

I think what you are trying to say is:
  "Metadata Class (MD Class):  The MD Class defines the scope of the 'Type'
field to
provide a hierarchical namespace.  The IANA Considerations section defines
how the
MD Class values can be allocated to Standards Bodies, Vendors, and others."

4) Sec 3.5.1:  For the Type, is this document mandating that the top bit of
the type field is the Criticality field?  If so - please say so.  For
example:

"The Type field is split into two ranges - 0 to 127 for non-critical
options and 128-255 for critical options.  While the value allocation is
the responsibility of the MD Class owner, critical options MUST NOT be
allocated from the 0 to 127 range and non-critical options MUST NOT be
allocated from the 128-255 range."

5) Sec 7.1:  "SI can also serve as a mechanism for loop detection within a
service
   path since each SF in the path decrements the index; an Service Index
   of 0 indicates that a loop occurred and the packet must be discarded."
It would be useful to explicitly say either "this is a protective mechanism
but loops aren't expected normally" or "although rare, looping is a risk as
a result of reconfiguring the SFP whlie
traffic is flowing."

6) Classifier:  It is noticeable that a Classifier is called out as having
special functions and behavior.  This isn't the case, that I recall, in the
SFC Architecture where a Classifier is merely an example of a Service
Function.  If this is intended, it would be good to be quite clear about it
and add more detail about what makes something a "Classifier" with this
role versus just a SF.  It feels like there are assumptions that flows go
to a Classifier to be assigned to an SFP but those aren't stated anywhere
I've seen so far.

7)  Sec 7.4: "These internal reclassifiers examine the packet
   at relevant points in the network, and rewrite the SPI and SI to
   reflect the results of the reclassification.  (These classifiers may
   also of course modify the metadata associated with the packet.)"

Previously - this was described as ability to remove the NSH header and then
replace it.   There are consequences to increasing the SI - is this
allowed?  The difference,
for example, in MPLS between pop/push and swap does matter.   What does a
rewrite of the NSH header mean versus removing it and writing a different
one?

8) Sec 8.3:   "A given SPI can represent all or some of the metadata, and
be updated based on metadata classification results."  Again - please be
clear about what functionality is allowed. Is it even meaningful to update
the SPI without updating the SI???

Nits:

i) Sec 7.1 Figures 9, 10, and 11 - please expand NH to be Next-Hops.

ii) Figure 14 and Figure 15 are identical.  Please correct or remove one.

iii) Sec 8.2 bullet 2:  It refers to Figure 18, which doesn't exist.

iv) Sec 8.3.  This refers to Figure 19 - not Figure 17.  Can I recommend
(probably too late) using the XML authoring which keeps these references up
to date automatically?

Regards,
Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 20:42:51 -0400

Alia, thank you for taking the time to do a thorough review.

I would like to comment on the OAM bit.  I understand your point.  It 
will take significant time to get even a significant portion of the OAM 
procedures (much less all of them) defined.

Would it make sense to turn the requirement around?  Could we say:
An SFF that receives a packet with the OAM bit set should determine if 
it supports any NSH based OAM procedures and encapsulations.  if so, it 
should consult those procedures for processing.  If it does not support 
any NSH based OAM procedures, it must discard received packets with the 
OAM bit set.

That way we are not held up waiting for agreement on a common OAM 
format, for which we do not yet have a starting point.  (We have various 
specific proposals for specific mechanisms.)

Yours,
Joel

On 6/6/16 8:17 PM, Alia Atlas wrote:
> like to thank Paul, Uri, and all the contributors and WG members who
> have done so much work on this.
>
> advance.  I haven't scrutinized the references for my review - but I
> would ask you to think about what should be normative so that someone
> can implement NSH.
>
>
> Major:
>
> implementer has no way to be compliant.  At a minimum, this should have
> a Normative Reference to the OAM procedures.
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 6 Jun 2016 21:11:52 -0400

Joel,

On Mon, Jun 6, 2016 at 8:42 PM, Joel M. Halpern <[email-masked]> wrote:

> I would like to comment on the OAM bit.  I understand your point.  It will
> take significant time to get even a significant portion of the OAM
> An SFF that receives a packet with the OAM bit set should determine if it
> supports any NSH based OAM procedures and encapsulations.  if so, it should
> consult those procedures for processing.  If it does not support any NSH
> based OAM procedures, it must discard received packets with the OAM bit set.
>

Sure - I'm not in favor of delaying NSH, though the idea of having deployed
without OAM or with mutually incompatible OAM isn't too appealing either.

Still, from an AD perspective, what matters is having clear and complete
specification.  What you suggest is one way.

Regards,
Alia

> That way we are not held up waiting for agreement on a common OAM format,
> for which we do not yet have a starting point.  (We have various specific
> proposals for specific mechanisms.)
>
> Yours,
> Joel
>
>

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Tue, 7 Jun 2016 01:44:41 +0000

Joel, Alia,

I do not think we should force discard. There may be implementations of
SFF/SF without OAM support added and there maybe OAM procedures that may
still be useful even if only part of a chain participates in an OAM
processing. 

So how about:

Sec 3.2:  " O bit: reserved for Operations, Administration and Maintenance
(OAM) message. SF/SFFs implemenations compliant to this specification
SHALL support configurable behaviour whether to discard the packet or
forward unmodified to the next element in the NSH-specified chain
regardless whether an SF/SFF supports the OAM procedures. OAM message
specifics and handling details are outside the scope of this document.

Andrew

On 2016-06-07, 8:42 AM, "sfc on behalf of Joel M. Halpern" wrote:

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

---

From: Alia Atlas <[email-masked]>
Date: Mon, 6 Jun 2016 21:46:58 -0400

Andrew,

I'm happy with whatever complete and clear specification the WG agrees with.
I certainly do see your point here - but am not sure what the behavior of
an SF
would be when given an OAM packet.

Regards,
Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 22:28:12 -0400

Given that blindly forwarding OAM packets is likely to produce 
unexpected results, I am inclined to conclude that an SFF who is 
configured to forward OAM packets better also know something about what 
it is doing.
In the absence of such knowledge, I have trouble seeing how anything 
other than dropping them is safe.

Yours,
Joel

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Tue, 7 Jun 2016 02:30:40 +0000

OAM CC would work. If I want to know whether my chain is up e2e, even if
SFF/SF does not support OAM-CC, forwarding a packet is better than
dropping.

Andrew

---

From: Dave Dolson <[email-masked]>
Date: Tue, 7 Jun 2016 02:48:02 +0000

I agree with Joel that unknown OAM types must be dropped. Some of the OAM schemes in discussion have required an echo, whereas others have required some kind of control-plane response. Forwarding such packets would cause havoc.

  Original Message
From: Joel M. Halpern
Sent: Monday, June 6, 2016 10:28 PM
To: Dolganow, Andrew (Nokia - SG); Alia Atlas
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] early AD review of draft-ietf-sfc-nsh-05

Yours,
Joel

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Tue, 7 Jun 2016 02:58:59 +0000

Dave,

Agree on you statement regarding bad result if OAM function is not
supported; however, I know of no case where an operator deployed OAM
function without understanding what it did. People just do not do this
type of things, and even if they did - the behaviour proposed will not to
produce instability - it will give more of ³garbage in garbage out² result.

By allowing configurable behaviour, we allow running e2e OAM that does not
require every element in a given chain to support every OAM function. This
is more flexible. I am OK to say SHALL drop and SHOULD support
configurable behaviour:

Sec 3.2:  " O bit: reserved for Operations, Administration and Maintenance
(OAM) message. SF/SFFs implemenations compliant to this specification
SHALL discard the packet be default when the bit is set and an SF/SFF does
not
supports the OAM procedure. SF/SFFs implementations compliant to
This specification SHOULD support configurable behaviour whether to
discard 
the packet or forward unmodified to the next element in the NSH-specified
chain
regardless whether an SF/SFF supports the OAM procedures. OAM message
specifics and handling details are outside the scope of this document.

Andrew

On 2016-06-07, 10:48 AM, "Dave Dolson" wrote:

>I agree with Joel that unknown OAM types must be dropped. Some of the OAM
>schemes in discussion have required an echo, whereas others have required
>some kind of control-plane response. Forwarding such packets would cause
>havoc.
>
>
>  Original Message
>From: Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 22:59:18 -0400

Actually, if one has an NSH aware SF that does not understand how CC is 
working, I have no idea what it will do with a CC packet.  So expecting 
it to work properly is rather optimistic.  We could try to mandate a 
default behavior for SF when presented with OAM packets, but "forward" 
is not always a natural action for an SF.  For example, a NAT does not 
forward packets unmodified.

In fact, in the discussions of OAM processing, we have strongly 
distinguished between testing an SF and testing an SFP.  Blindly handing 
OAM packets that are testing SFP to an SF is likely to produce odd results.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 22:59:48 -0400

I will note that this discussion confirms Alia's point that we do need 
to be clear about the handling.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 23:01:21 -0400

I have no problem with a knob that says "if you get an OAM packet like 
<this>, just forward it."  But that is a form of knowledge.
A knob that says "Just forward OAM packets" is liable to break things.

Yours,
Joel

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 7 Jun 2016 03:09:52 +0000

Dear All,
I can refer to the Residence Time Measurement work as an example where dropping the OAM packet would break the process. Though the RTM in MPLS network relies on calculation of the TTL value by RTM-capable node I can imagine solution where the OAM packet being passed from LSR to LSR, the LDP environment for example, so that only ones that are capable to measure the residence time would do the processing. In some way this is similar to Linktrace function in Ethernet OAM where the LTM frame gets forwarded along the path while nodes with properly configured MIP generate LTR back to the sender. If a transient node that doesn't understand LTM operation to drop frames, that would produce hard to debug situation.

	Regards,
		Greg

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, June 06, 2016 7:48 PM
To: Joel M. Halpern; Dolganow, Andrew (Nokia - SG); Alia Atlas
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] early AD review of draft-ietf-sfc-nsh-05

  Original Message
From: Joel M. Halpern

Given that blindly forwarding OAM packets is likely to produce unexpected results, I am inclined to conclude that an SFF who is configured to forward OAM packets better also know something about what it is doing.
In the absence of such knowledge, I have trouble seeing how anything other than dropping them is safe.

Yours,
Joel

On 6/6/16 9:44 PM, Dolganow, Andrew (Nokia - SG) wrote:
> Joel, Alia,
>
> I do not think we should force discard. There may be implementations 
> of SFF/SF without OAM support added and there maybe OAM procedures 
> that may still be useful even if only part of a chain participates in 
> an OAM processing.
>
> So how about:
>
>> will take significant time to get even a significant portion of the 
>> OAM procedures (much less all of them) defined.
>>
>> An SFF that receives a packet with the OAM bit set should determine 
>> if it supports any NSH based OAM procedures and encapsulations.  if 
>> so, it should consult those procedures for processing.  If it does 
>> not support any NSH based OAM procedures, it must discard received 
>> packets with the OAM bit set.
>>
>> format, for which we do not yet have a starting point.  (We have 
>> various specific proposals for specific mechanisms.)
>>
>> Yours,
>> Joel
>>
>>> I have done an early AD review of draft-ietf-sfc-nsh-05. First, I 
>>> would like to thank Paul, Uri, and all the contributors and WG 
>>> members who have done so much work on this.
>>>
>>> Second, this document still needs a lot of work before it is ready 
>>> to advance.  I haven't scrutinized the references for my review - 
>>> but I would ask you to think about what should be normative so that 
>>> someone can implement NSH.
>>>
>>>
>>> Major:
>>>
>>> a) Sec 3.2:  " O bit: when set to 0x1 indicates that this packet is 
>>> an Operations,
>>> I am quite concerned that this document requires (MUST) conformance 
>>> to a document that isn't in any way referenced or specified.  
>>> Basically, an implementer has no way to be compliant.  At a minimum, 
>>> this should have a Normative Reference to the OAM procedures.
>>>
>>> If truly necessary, another way out would be to reserve this bit for 
>>> OAM but save the definition and behavior for the OAM draft.  That'd 
>>> be unfortunate in that implementations could conform to NSH but not 
>>> the associated OAM.
>>

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Tue, 7 Jun 2016 03:13:04 +0000

Jack,

Back to my fundamental assumption. People do not just turn e2e features in
real life without knowing what they do. Tons of today's SDN-(r)evolution,
including SFC work is driven by network inflexibility to support new
things. The below at least gives you a basic level of interop when some
OAM functions do not require every element upgrade.

Andrew

On 2016-06-07, 11:01 AM, "Joel M. Halpern" wrote:

>>>>of
>>>>>OAM
>>>>>if
>>>>> various
>>>>>> would
>>>>>>to
>>>>>>an
>>>>>> to a
>>>>>> OAM

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 23:37:33 -0400

The converse situation is that the operator originates OAM packets, 
thinking everything is configured right, and some devices have not been 
updated.  Dropping the packets produces problems, but they are problems 
that will lead the operator to the failure.
Forwarding them in the wrong places can produce much worse results.

Yours,
Joel

On 6/6/16 11:34 PM, Dolganow, Andrew (Nokia - SG) wrote:
> Joel,
>
> Sorry for auto-correct misspelling  of you name.
>
> Andrew
>
> Sent from my iPhone
>
>> On Jun 7, 2016, at 11:13 AM, Dolganow, Andrew (Nokia - SG) <[email-masked]> wrote:
>>
>> Jack,
>>

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Tue, 7 Jun 2016 04:39:25 +0000

Joel,

I think we can prevent this with appropriate text around “SHOULD” option.
In the spec and in the subsequent OAM drafts. That will make operators
careful and will not prevent flexibility where some functions like I or
Greg shown may still offer value without e2e OAM support.

Andrew

On 2016-06-07, 11:37 AM, "Joel M. Halpern" wrote:

>>>>> type of things, and even if they did - the behaviour proposed will
>>>>>not
>>>>> to
>>>>> By allowing configurable behaviour, we allow running e2e OAM that
>>>>>does
>>>>> not
>>>>>> I agree with Joel that unknown OAM types must be dropped. Some of
>>>>>>the
>>>>>> OAM
>>>>>>> SFF/SF without OAM support added and there maybe OAM procedures
>>>>>>>that
>>>>>>> may
>>>>>>>> it supports any NSH based OAM procedures and encapsulations.  if
>>>>>>>>so,
>>>>>>>> it
>>>>>>>> any NSH based OAM procedures, it must discard received packets
>>>>>>>>with
>>>>>>>> the
>>>>>>>> OAM bit set.
>>>>>>>>
>>>>>>>>>   Administration and Maintenance (OAM) message.  The receiving
>>>>>>>>>SFF
>>>>>>>>> and
>>>>>>>>> document that isn't in any way referenced or specified.
>>>>>>>>>Basically,
>>>>>>>>> an
>>>>>>>>> implementer has no way to be compliant.  At a minimum, this
>>>>>>>>>should
>>>>>>>>> have

---

From: <[email-masked]>
Date: Tue, 7 Jun 2016 06:10:16 +0000

Dear Alia, all, 

FWIW, an issue was filled in tracker for this since Apr 2015: https://www.ietf.org/mail-archive/web/sfc/current/msg03447.html  

The text that was agreed during the WGLC to address the issue is this one:

>    O bit: Setting this bit indicates an Operations,
>    Administration, and Maintenance
>    (OAM) packet.  The actual format and processing of SFC OAM messages
>    is outside the scope of this specification (see [I-D.ietf-sfc-oam-framework]).
>
>    For data (i.e., not OAM) packets, the O bit MUST be cleared and MUST NOT
>    be modified along the SFP.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
> Envoyé : mardi 7 juin 2016 02:43
> À : Alia Atlas; [email-masked]; [email-masked]
> Objet : Re: [sfc] early AD review of draft-ietf-sfc-nsh-05
>

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Tue, 7 Jun 2016 09:31:35 +0000

The problem with this text is that it does not specify what to do if you
compliant to NSH draft but not OAM draft - this leads to undefined
behaviour - hence the discussion we have been having. Some of the below
text though is an enhancement over what we have been discussion (last
paragraph, reference to OAM draft).

Andrew

On 2016-06-07, 2:10 PM, "sfc on behalf of [email-masked]"
wrote:

>Dear Alia, all, 
>
>FWIW, an issue was filled in tracker for this since Apr 2015:
>https://www.ietf.org/mail-archive/web/sfc/current/msg03447.html
>

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 7 Jun 2016 11:33:44 +0200

Hello Alia,

Le 07/06/2016 02:17, Alia Atlas a écrit :
>    First, there seem to be a number of assumptions in this paragraph
> about Classifiers - including that there is only one per service
> function path ("MUST send the packet to the first SFF in the chain") -
> despite earlier discussion of re-classification.   PLEASE - pull out the
> description of the field such as:
>
>    "The Service Index provides a location within the SFP.  The index
> should strictly decrease from its initial value.  The function that
> encapsulates the packet in NSH SHOULD set the SI to 255.  SI MUST be
> decremented..."

I am not sure about that. An SFC Proxy will do such encapsulation but it 
can sit in the middle of a chain. It is true that the use of SHOULD 
enables the proxy not to follow that recommendation, but I wonder if we 
couldn't find another way to address your valid point on re-classification.
I note that the existing text mentions "the first classifier" in the 
first sentence. Couldn't the second sentence be scoped and thus be:
    The *first* classifier MUST send the packet to the first SFF in the
    chain.

Regards,
Martin

---

From: <[email-masked]>
Date: Tue, 7 Jun 2016 11:47:24 +0000

Re-,

The NEW text declares the specification of O-bit=1 out of scope. Only the case of O-bit unset is covered in the NSH spec. 

I don't see an issue there. 

Cheers,
Med

> De : Dolganow, Andrew (Nokia - SG) [mailto:[email-masked]]
> Envoyé : mardi 7 juin 2016 11:32
> À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Alia Atlas; [email-masked];
> [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 7 Jun 2016 07:48:06 -0400

Can you suggest what that text would look like?
I can well believe that there is better text than what I proposed.

Yours,
Joel

---

From: Alia Atlas <[email-masked]>
Date: Tue, 7 Jun 2016 09:09:34 -0400

Dear Med,

Yes, I read version -05 yesterday where that text is.
I do not believe that it is not sufficient for interoperability.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 7 Jun 2016 09:46:02 -0400

Hi Martin,

On Tue, Jun 7, 2016 at 5:33 AM, Martin Vigoureux <[email-masked]

> can sit in the middle of a chain. It is true that the use of SHOULD enables
> the proxy not to follow that recommendation, but I wonder if we couldn't
> find another way to address your valid point on re-classification.
> I note that the existing text mentions "the first classifier" in the first
> sentence. Couldn't the second sentence be scoped and thus be:

I'm certain that there are better ways of phrasing it than I suggested; I
was trying to separate special previously undefined behavior for a
classifier versus rules for SI..  It might help to define more clearly the
different possible behaviors associated with NSH - much like MPLS has push,
pop, and swap.

Regards,
Alia

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Thu, 9 Jun 2016 03:58:02 +0000

OK,

Here is an option. I am using Mohamed’s, your's and my text combination
As base:

O bit: Setting this bit indicates an Operations, Administration, and
Maintenance (OAM) packet.  The actual format and processing of SFC OAM
Messages is outside the scope of this specification (see
[I-D.ietf-sfc-oam-framework]).

SF/SFFs implementations compliant to this Specification SHALL discard
the packet be default when the bit is set and an SF/SFF does not supports
OAM procedures. 

SF/SFFs implementations compliant to this specification MAY support
configurable behaviour to forward the received OAM packet unmodified
to the next element in the NSH-specified chain. Such behaviour may be
acceptable for a subset of OAM functions but can result in unexpected
behaviour for others, thus it is recommended to analyze the impact of
forwarding an OAM packet for all OAM functions deployed prior
to enabling the forwarding.

    For data (i.e., not OAM) packets, the O bit MUST be cleared and MUST
NOT
    be modified along the SFP.

Andrew

On 2016-06-07, 7:48 PM, "sfc on behalf of Joel M. Halpern" wrote:

>>>>>>> require every element in a given chain to support every OAM
>>>>>>>function.
>>>>>>> This
>>>>>>> SHALL discard the packet be default when the bit is set and an
>>>>>>>SF/SFF
>>>>>>> does
>>>>>>> not
>>>>>>>>> SHALL support configurable behaviour whether to discard the
>>>>>>>>>packet
>>>>>>>>> or
>>>>>>>>>> I would like to comment on the OAM bit.  I understand your
>>>>>>>>>>point.
>>>>>>>>>> It
>>>>>>>>>>> like to thank Paul, Uri, and all the contributors and WG
>>>>>>>>>>>members
>>>>>>>>>>> who
>>>>>>>>>>> a) Sec 3.2:  " O bit: when set to 0x1 indicates that this
>>>>>>>>>>>packet
>>>>>>>>>>> is
>>>>>>>>>>> an
>>>>>>>>>>> Operations,
>>>>>>>>>>>   SFs nodes MUST examine the payload and take appropriate
>>>>>>>>>>>action
>>>>>>>>>>> (e.g.
>>>>>>>>>>> If truly necessary, another way out would be to reserve this
>>>>>>>>>>>bit
>>>>>>>>>>> for
>>>>>>>>>>> OAM
>>>>>>>>>>> unfortunate in that implementations could conform to NSH but
>>>>>>>>>>>not
>>>>>>>>>>> the
>>>>>>>>>>> associated OAM.
>>>>>>>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Jun 2016 00:39:26 -0400

That works for me.
Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 9 Jun 2016 11:14:42 +0000

Hi Andrew, 

Thank you for sharing this proposal. IMHO, the configurable behavior should be disabled by default. 

Please find below an updated text proposal:

=============
   O bit: Setting this bit indicates an Operations, Administration, and
   Maintenance (OAM) packet.  The actual format and processing of SFC
   OAM messages is outside the scope of this specification (see [I-
   D.ietf-sfc-oam-framework]).

   SF/SFF implementations, which do not support SFC OAM procedures,
   SHALL discard packets with O-bit set.

   SF/SFF implementations MAY support a configurable parameter to enable
   forwarding received SFC OAM packets unmodified to the next element in
   the chain.  Such behavior may be acceptable for a subset of OAM
   functions, but can result in unexpected outcomes for others, thus it
   is recommended to analyze the impact of forwarding an OAM packet for
   all OAM functions prior to enabling this behavior.  The configurable
   parameter MUST be disabled by default.

   For data (i.e., not OAM) packets, the O-bit MUST be cleared and MUST
   NOT be modified along the SFP.
==========

Cheers,
Med

> Envoyé : jeudi 9 juin 2016 05:58
> À : Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> Here is an option. I am using Mohamed's, your's and my text combination
> As base:
> 
> >> I think we can prevent this with appropriate text around "SHOULD"
> >>option.
> >>>>>>> produce instability - it will give more of ³garbage in garbage
> out²
> >>>>>>> result.
> >>>>>>>
> >>>>>>>> some kind of control-plane response. Forwarding such packets
> would
> >>>>>>>> cause
> >>>>>>>> havoc.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Original Message
> >>>>>>>> From: Joel M. Halpern
> >>>>>>>> configured to forward OAM packets better also know something
> about
> >>>>>>>> what
> >>>>>>>> it is doing.
> >>>>>>>>>>> but save the definition and behavior for the OAM draft.
> That'd
> >>>>>>>>>>> be

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 9 Jun 2016 12:16:55 +0000

This looks good to me ..

Jim

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Thu, 9 Jun 2016 14:11:55 +0000

Agree

Andrew

Sent from my iPhone

> On Jun 9, 2016, at 8:17 PM, Jim Guichard (jguichar) <[email-masked]> wrote:
> 
> This looks good to me ..
> 
> Jim
> 
> 
> 
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 13 Jun 2016 15:12:50 +0000

Hi Alia,

Catching up an email post-vaction, sorry for the delay. 

On Jun 6, 2016, at 8:17 PM, Alia Atlas <[email-masked]> wrote:
> 
> I have done an early AD review of draft-ietf-sfc-nsh-05. First, I would like to thank Paul, Uri, and all the contributors and WG members who have done so much work on this.
> 

PQ>  And thank you for the thorough and thoughtful review!

> Second, this document still needs a lot of work before it is ready to advance.  I haven't scrutinized the references for my review - but I would ask you to think about what should be normative so that someone can implement NSH.
> 

PQ>  We'll make sure to review the references but I will add that a slew of implementations exist, so, thus far, this hasn't been an impediment.  

> 
> Major:
> 
> a) Sec 3.2:  " O bit: when set to 0x1 indicates that this packet is an Operations,
> I am quite concerned that this document requires (MUST) conformance to a document that isn't in any way referenced or specified.  Basically, an implementer has no way to be compliant.  At a minimum, this should have a Normative Reference to the OAM procedures.  
> 
> If truly necessary, another way out would be to reserve this bit for OAM but save the definition and behavior for the OAM draft.  That'd be unfortunate in that implementations could conform to NSH but not the associated OAM.

PQ>  I see that a whole thread re: OAM, I'll comment there.

> b) Sec 3.2:  I have three points on the "Next Protocol" field.  First, please read Section 8 of draft-ietf-rtgwg-dt-encap-01, which discusses the issue of each encapsulation defining its own Next Protocol field.  Please take a look at VXLAN-GPE, GUE, GENEVE, and BIER to see which of those "Next Protocol" fields can merge to be the same registry.  I know that one of them is currently using EtherType, but at least 1 or 2 others also has an 8-bit "Next Protocol" field.   The name should also be improved to be much clearer as to what it is, what types of protocols might fit in it, and how it might be extended or reused.  These obviously apply to Sec 13.2.5 as well.

PQ>  At this point, NSH and VXLAN-GPE have the same space (i.e. on allocation).  We can certainly look into leveraging that for other protocols as well.  As for the name, I'm not sure how to make it clearer since the name describes the purpose.  

>    taking into account the length of the service function path).  A Classifier 
>   First, there seem to be a number of assumptions in this paragraph about Classifiers - including that there is only one per service function path ("MUST send the packet to the first SFF in the chain") - despite earlier discussion of re-classification.   PLEASE - pull out the description of the field such as:
> 
>   "The Service Index provides a location within the SFP.  The index should strictly decrease from its initial value.  The function that encapsulates the packet in NSH SHOULD set the SI to 255.  SI MUST be decremented..."

PQ>  We'll clarify the role/behavior of classifiers and SI and provide text for your/WG review by June 24.

> 
> from normative behavior for a Classifier and text describing why the field is useful.
> I am assuming that there are more details around troubleshooting and service plane loop detection elsewhere?
> 
> d) Sec 3.4:  What is the required behavior for parsing the "Mandatory Context Header" fields?  Can an implementation support just what is in this document?  Do the documents on allocation also describe the appropriate parsing?  I see them as informative references.  Can an implementation ignore the contents of the "Mandatory Context Header" fields?  Without a normative reference to how this is to be implemented, received, and parsed, I don't see that this provides implementable and complete behavior.
> 

PQ>  Can you please delve into a bit more detail re: "parsing behavior"?  An implementation can indeed support just what is in this document, as we have open source systems that do just that.   The context headers fields are simply space, their semantics conveyed by control plane (dynamic or static).  The allocation drafts provide usage guidelines, but of course, an operator may chose to assign values as needed for their deployment.

> e) Sec 6:  This section needs work. First, please read sec 9 of draft-ietf-rtgwg-dt-encap-01 for some ideas.  At a minimum, you need to clarify what the mandatory behavior is and what the failure conditions or results are.   For more details:  Jumbo Frames help only when the packet or frame being encapsulated isn't already at the maximum.  I fully agree that is likely to the case for much traffic - but it isn't the guaranteed solution this tries to treat it as.   Sure - it is possible to determine the Path MTU - but is that to the next SFF or through the entire SFP?  Can it be the whole SFP when re-classification may change what the desired path is?  What happens at an SFF if it determines that the Path MTU beyond is too small?  What are the consequences of fragmenting by the transport?   As for the third example from RFC6830 - I'm assuming you mean the stateless case - which basically amounts to determining a Path MTU and then fragmenting.
> 
> The Path MTU approaches don't handle at all the case of adding context-headers by an SF in the middle of the path.  That can obviously require fragmenting the packet and then adding NSH headers which is specifically not expected at the SF or SFF (see Sec 4).
> 
> These approaches also assume that it is possible to fragment the data contained inside the NSH header.  In the case of something like an Ethernet frame, that isn't the case..
> 
> The likely short form is that the network operator sets a different MTU inside the space for the SFP which can accommodate a given size of header.  The Classifiers and SFF/SFs are set up to send some type of error messages and log and drop the offending packets or frames if they are too large.  If the next-protocol type can be fragmented, then there is more functionality to define/describe.  Regardless, the consequences of unexpected fragmentation should be clearly articulated and ways of detecting it discussed. 

PQ>  Uri and I will update the fragmentation section to address your concerns and send text for review, again by June 24th

> 
> f) Sec 8.1:  Privacy considerations will matter for information such as VRF or tenant, depending on how those are expressed and trackable.   Similarly, the security implications of an SF terminating  encrypted traffic will need to be articulated.
> 
> g) Sec 9:  This section needs to be pulled out into its own draft.  That draft should describe the considerations associated with carrying NSH.   Regardless, it is not acceptable for the WG to partially and minimally document the "preferred transports" by providing them as "encapsulation examples" while pushing strongly back against less-preferred transports (e.g. the discussions around UDP and MPLS).  The fact that this section has no words and merely gives self-evident examples - such as Sec 9.3 where an Ethernet Frame indicates the included type using the EtherType - makes it look quite strongly as if it is simply providing examples so others can implement without straying into transport details.

PQ>  There is no intent to convey preference here, rather to demonstrate to a reader how NSH fits into the stack for a few _example_ transports.  Having worked with many of the implementors, I know how often this question get asked so having simple examples that we can point to has proved invaluable.  We can certainly add text to that affect, and, in the case of UDP, there is UDP+NSH draft that can easily be pointed to as an informative reference.  

> 
> h) I will also note that the suggested EtherType=0x894F is registered with IEEE as "
> This protocol identifies the Cisco vPath Network Service Header protocol used in inserting and chaining services in the network."   I am checking with IEEE as to whether they allow changes in the protocol meant; certainly, IETF managed registries do not due to the interoperability concerns.  Regardless, there are experimental EtherTypes and after this document finally has IESG approval, the IEEE will allocate an EtherType for NSH.

PQ>  I believe (can check the archive) but Cisco has asserted that this ET is to be used by the IETF for NSH.  We are working through the allocation update with the IEEE.

> 
> i) The Security Considerations section says nothing about privacy around metadata.  It refers informationally to draft-reddy-sfc-nsh-security-req-00, which gives requirements but no mechanisms.  Obviously, that doesn't adequately address the security concerns.  The WG Chairs are welcome to request an early Security Directorate review to see the types and level of issues that will come up.

PQ>  As per the chair's guidance, the WG formed a security team to author corollary drafts for security.  We'll -- NSH and the security team (full disclosure: I'm part of both groups) -- work together to ensure completeness in NSH and augment this section.

> 
> j) Sec 13.2.4:  First, this requires text describing what rules the DE should apply.  Second, I would recommend having part of the range be Specification Required and that a specification is required by the Designated Experts also.  There probably should be a Private Use section for companies that need a private section.  Take a read through https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ to get full context on what is expected.

PQ>  Thank you, Andy Mallis also provided corrections/guidance here.  We'll update accordingly.  

> 
> 
> 
> Minor:
> 
> 1) Sec 3.2: Please add an informational reference for the "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."  That could be either RFC 7325 or Section 8 of draft-ietf-rtgwg-dt-encap-01.

PQ>  Will do.

> 
> 2) Sec 3.2:  "All other flag fields are reserved for future use.  Reserved bits

PQ>  Has the SHOULD become the accepted way forward?  The reason I asked, both RFC7348 and 6830 use MUST.  I just want to ensure consistent behavior.  

> 
> I think that this is better as "SHOULD be ignored upon receipt" to handle future
> extensions.  I know I've had this conversation several times on different drafts.
> 
> 3) Sec 3.5.1: "Metadata Class (MD Class): describes the scope of the "Type" field.
>   "Metadata Class (MD Class):  The MD Class defines the scope of the 'Type' field to
> provide a hierarchical namespace.  The IANA Considerations section defines how the

PQ>  Yes. thank you.

> 
> 4) Sec 3.5.1:  For the Type, is this document mandating that the top bit of the type field is the Criticality field?  If so - please say so.  For example:
> 
> "The Type field is split into two ranges - 0 to 127 for non-critical options and 128-255 for critical options.  While the value allocation is the responsibility of the MD Class owner, critical options MUST NOT be allocated from the 0 to 127 range and non-critical options MUST NOT be allocated from the 128-255 range."

PQ>  Thanks.

> 
> 5) Sec 7.1:  "SI can also serve as a mechanism for loop detection within a service
> It would be useful to explicitly say either "this is a protective mechanism but loops aren't expected normally" or "although rare, looping is a risk as a result of reconfiguring the SFP whlie 
> traffic is flowing."
> 

PQ>  We'll review, we might have some other updates to this section as well with a target of June 24 to share the text.

> 6) Classifier:  It is noticeable that a Classifier is called out as having special functions and behavior.  This isn't the case, that I recall, in the SFC Architecture where a Classifier is merely an example of a Service Function.  If this is intended, it would be good to be quite clear about it and add more detail about what makes something a "Classifier" with this role versus just a SF.  It feels like there are assumptions that flows go to a Classifier to be assigned to an SFP but those aren't stated anywhere I've seen so far.

PQ>  Uri and I will talk to Joel and Carlos but I think classifier is special in some ways and not simply an SF.  We'll make sure the roles are clearly spelled out in whatever we send on June 24th to the list.

> replace it.   There are consequences to increasing the SI - is this allowed?  The difference,
> for example, in MPLS between pop/push and swap does matter.   What does a rewrite of the NSH header mean versus removing it and writing a different one?
> 
> 8) Sec 8.3:   "A given SPI can represent all or some of the metadata, and be updated based on metadata classification results."  Again - please be clear about what functionality is allowed. Is it even meaningful to update the SPI without updating the SI???

PQ>  Uri and I will provide text for review by June 24

> iv) Sec 8.3.  This refers to Figure 19 - not Figure 17.  Can I recommend (probably too late) using the XML authoring which keeps these references up to date automatically?
> 
> 

PQ>  Will update.

Again, thank you for the review!
Paul

---

From: "Elzur, Uri" <[email-masked]>
Date: Wed, 15 Jun 2016 02:06:53 +0000

Sorry for radio silence, coming back from international trip and sick at the moment, so will get to it ASAP
Few quick comments
1) we have text providing for additional Classifiers in the chain and it will be easy to make it clearer
2) Transport: cite them all - impossible. Cite none - hard on the implementers, cite few that deemed to be popular and well understood as open source exists was the choice. 

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Monday, June 13, 2016 8:13 AM
To: Alia Atlas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] early AD review of draft-ietf-sfc-nsh-05

Hi Alia,

> The likely short form is that the network operator sets a different MTU inside the space for the SFP which can accommodate a given size of header.  The Classifiers and SFF/SFs are set up to send so…

PQ>  Uri and I will update the fragmentation section to address your 
PQ> concerns and send text for review, again by June 24th

PQ>  Will do.

> 
> I think that this is better as "SHOULD be ignored upon receipt" to 
> handle future extensions.  I know I've had this conversation several times on different drafts.
> 
>   "Metadata Class (MD Class):  The MD Class defines the scope of the 
> 'Type' field to provide a hierarchical namespace.  The IANA 
> Considerations section defines how the MD Class values can be allocated to Standards Bodies, Vendors, and others."

PQ>  Yes. thank you.

PQ>  Thanks.

> It would be useful to explicitly say either "this is a protective 
> mechanism but loops aren't expected normally" or "although rare, looping is a risk as a result of reconfiguring the SFP whlie traffic is flowing."
> 

PQ>  Will update.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 29 Jun 2016 13:31:52 +0000

Alia,

As per the initial replies below, here is updated/suggested text, prefaced by ----NEW TEXT---- for the perviously unaddressed comments.  Apologies for the delay, some business travel slowed things down. (the original reply was trimmed for readability)

Again, thank you for your detailed review!

Paul

> On Jun 13, 2016, at 11:12 AM, Paul Quinn (paulq) <[email-masked]> wrote:
> 
> Hi Alia,
> 

----NEW TEXT----
c) "Service Index (SI): provides location within the SFP. The
initial classifier for a given SFP SHOULD set the SI to 255, however the
control   plane MAY configure the initial value of SI as appropriate
(i.e.   taking into account the length of the service function path).  
Service Index MUST be decremented by Service Functions or by SFC Proxy
nodes   after performing required services and the new decremented SI
value   MUST be used in the egress NSH packet.   The initial Classifier
MUST send the packet to the first SFF in the identified SFP  for
forwarding along an SFP. If re-classification occurs, and that
re-classification results in a new SPI, the (re)classifier is, in
effect, the initial classifier for the resultant SPI.

SI SHOULD be used in conjunction with Service Path Identifier for
Service Function Path   Selection and for determining the next SFF/SF in
the path.  Service Index (SI) is also valuable when troubleshooting/
reporting service paths.  In addition to indicating the location
within a Service Function Path, SI can be used for service plane loop
detection."

--------

<trimmed>

---- NEW TEXT ----

NSH and the associated transport header are "added" to the
encapsulated packet/frame.  This additional information increases the
size of the packet.  
   
As discussed in [draft-ietf-rtgwg-dt-encap-01], within an administrative domain,
an operator can ensure that the underlay MTU is sufficient to carry SFC traffic
without requiring fragmentation.  
   
However, there will be cases where the underlay MTU is not large enough to carry the
NSH traffic.  Since NSH does not provide fragmentation support at the service plane,
the transport/overlay layer MUST provide the requisite fragmentation handling.  Section
6 of [draft-ietf-rtgwg-dt-encap-01] provides guidance for those scenarios. 

--------

<trimmed>

---- NEW TEXT ----

Depending on the information carried in the metadata, data privacy
considerations may need to be considered.  For example, if the metadata
conveys tenant information, that information may need to be
authenticated and/or encrypted between the originator and the intended
recipients (which may include intended SF’s only) .  NSH itself does not
provide privacy functions, rather it relies on the transport/overlay
layer.  An operator can select the appropriate transport to ensure the
confidentially (and other security) considerations are met.

(not text for the draft) re: SF termination.  Although the point is
valid, it is orthogonal to the draft.  We can certainly insert a
statement that mentions "SF security is outside the scope of NSH" since
the implications are likely SF-specific and SFC did not impose new
requirements there.

--------

---- NEW TEXT ----

   As with many other protocols, NSH data can be spoofed or otherwise
   modified.  In many deployments, NSH will be used in a controlled
   environment, with trusted devices (e.g. a data center) thus
   mitigating the risk of unauthorized header manipulation.

   NSH is always encapsulated in a transport protocol and therefore,
   when required, existing security protocols that provide authenticity
   (e.g.  [RFC6071]) can be used.  Similarly if confidentiality is
   required, existing encryption protocols can be used in conjunction
   with encapsulated NSH.

   Further, existing best practices, such as [BCP38] should be deployed
   at the network layer to ensure that traffic entering the service path
   is indeed "valid".  [draft-ietf-rtgwg-dt-encap-01.txt] provides
   additional transport encapsulation considerations.

    NSH metadata authenticity and confidentially must be considered as
    well.  In order to protect the metadata, an operator can leverage
    the aforementioned mechanisms provided the transport layer,
    authenticity and/or confidentiality. An operator MUST carefully
    select the transport/underlay services to ensure end to end security
    services, when those are sought after.  For example, if [RFC6071] is
    used, the operator MUST ensure it can be supported by the
    transport/underlay of all relevant network segments as well as SFF
    and SFs.

	Lastly, SF security, although out of scope of this document, should
	be considered, particularly if an SF needs to access, authenticate
	or update NSH metadata.

   Further security considerations are discussed in [nsh-sec].

-------

---- NEW TEXT ----

SI serves as a mechanism for detecting invalid service function
path. In particular an SI value of zero indicates that forwarding is incorrect and the packet must be discarded

(note: thank you to Don Fedyk who has suggested some new text in this space that is being reviewed and incorporated)

-------

---- NEW TEXT ---

While a given realized service function path is a specific sequence
of service functions, the service as seen by a user can actually be a
collection of service function paths, with the interconnection
provided by classifiers (in-service path, non-initial
reclassification).  These internal reclassifiers examine the packet
at relevant points in the network, and, if needed, SPI and SI are updated (whether
this update is a re-write, or the imposition of a new NSH with new values is implementation
specific) to reflect the "result" of the classification.  These classifiers may also 
of course modify the metadata associated with the packet.
RFC7665, section 2.1 describes Service Graphs in detail.

---------

---- NEW TEXT ----
  Metadata information may influence the service path selection since
   the Service Path Identifier values can represent the result of
   classification.  A given SPI can be defined based on classification results (including metadata classification).  
   The imposition of the SPI (new or an change of existing) results, as previously described,
   in the defintion of a new SFP and the SI value much reflect the new SFP accordingly.  
   
   This relationship provides the ability to create a dynamic service
   plane based on complex classification without requiring each node to
   be capable of such classification, or requiring a coupling to the
   network topology.  This yields service graph functionality as
   described in Section 7.4.  Figure 19 illustrates an example of this
   behavior.

-------