Subject: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Oct 2016 12:28:30 +0000

Dear SFC WG:

The following text has been proposed by Med and Lucy as an addition to section 3.4 of draft-ietf-sfc-nsh:

"This specification allows defining different semantics of metadata type 1 related mandatory context header, but the NSH header does not convey that semantic in the context headers. An SFC-aware SF MUST receive the data extraction schema first in order to get the data placed in the mandatory context header. How an SFC-aware SF gets the data extraction schema for the mandatory context header is outside the scope of this specification. This specification does not make any assumption about the content placed in the mandatory context header. Upon receiving an SFC packet with metadata type 1 present, if an SFC-aware SF is configured to use metadata but does not yet receive the data extraction schema for the mandatory context header, it MUST NOT process the packet and MUST log this error."

Before asking the editors of the document to make this change, I would like to hear opinions from other WG members so that consensus for this change may be reached. I would particularly like to hear opinions on the last sentence; specifically the ‘MUST NOT process’ as this implies that an SF must drop a packet if it is unable to process the metadata thereby breaking the chain. Do we need to be this strict or can we simply log an error and forward the packet through the chain?

Jim

---

From: <[email-masked]>
Date: Wed, 26 Oct 2016 13:02:17 +0000

Jim,

I fully agree with this text change, unsurprisingly.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mercredi 26 octobre 2016 14:29
À : [email-masked]
Objet : [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Dear SFC WG:

Jim

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Oct 2016 13:11:03 +0000

Jim,

If we choose not to put a schema ID in the header itself (pending near-term discussion, it would seem), then this text looks like a good start.    One additional concept that I think we could introduce is the granularity of the binding of the metadata extraction schema.   The metadata extraction schema could be associated to an individual SFP, a numerical range of SFP IDs, or all SFPs in the administrative domain.   Interpretation across administrative domains is out of scope.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 26, 2016 8:29 AM
To: [email-masked]
Subject: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Dear SFC WG:

Jim

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Wed, 26 Oct 2016 14:49:57 +0000

Looks good. It will do magic. The remaining consideration I have is around a reduced prescription about the Opaqueness of the content.

To address this, what about the following text suggestion?

s/This specification allows defining different semantics of metadata type 1 related mandatory context header, but the NSH header does not convey that semantic in the context headers/This specification allows defining different semantics of metadata type 1 related mandatory opaque context header, but the NSH header does not convey that semantic in the context or base NSH headers/

G/

From: sfc <[email-masked]> on behalf of "Jim Guichard (jguichar)" <[email-masked]>
Date: Wednesday, 26 October 2016 at 14:28
To: "[email-masked]" <[email-masked]>
Subject: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Dear SFC WG:

Jim

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 26 Oct 2016 11:56:02 -0500

Jim,

I support this addition. If an SF receives an SFC packet but doesn’t have
the necessary data extraction schema, how can it properly process the
packet?

You also asked whether the packet should be forwarded or dropped at this
point. Presumably the chain has been established in a particular order so
that the SFs can process the packet in a waterfall process. If one of the
SFs cannot process the packet properly, then the waterfall process has been
broken, and the packet really should be dropped, since the subsequent SFs
in the chain may not have the proper state in place to process the packet,
even if they have the schema.

Cheers,
Andy

On Wed, Oct 26, 2016 at 7:28 AM, Jim Guichard (jguichar) <[email-masked]
> wrote:

> "This specification allows defining different semantics of metadata type 1
> related mandatory context header, but the NSH header does not convey that
> semantic in the context headers. An SFC-aware SF MUST receive the data
> extraction schema first in order to get the data placed in the mandatory
> context header. How an SFC-aware SF gets the data extraction schema for the
> mandatory context header is outside the scope of this specification. This
> specification does not make any assumption about the content placed in the
> mandatory context header. Upon receiving an SFC packet with metadata type 1
> present, if an SFC-aware SF is configured to use metadata but does not yet
> receive the data extraction schema for the mandatory context header, it
> MUST NOT process the packet and MUST log this error."
>
> Before asking the editors of the document to make this change, I would
> like to hear opinions from other WG members so that consensus for this
> change may be reached. I would particularly like to hear opinions on the
> last sentence; specifically the ‘MUST NOT process’ as this implies that an
> SF must drop a packet if it is unable to process the metadata thereby
> breaking the chain. Do we need to be this strict or can we simply log an
> error and forward the packet through the chain?
>
> Jim
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Oct 2016 19:19:01 +0000

Dear SFC WG:

One further point for discussion.

In the first sentence, would it not be more accurate to say “but the NSH base header does not convey that semantic…” rather than “but the NSH header does not convey that semantic in the context headers”.. The reason I ask this is two-fold; 1. The NSH base specification does not define the type-1 metadata but leaves it as opaque for specification elsewhere, and 2. The third sentence says "This specification does not make any assumption about the content placed in the mandatory context header”.

Jim

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Jim Guichard <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 26, 2016 at 8:28 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Dear SFC WG:

Jim

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 26 Oct 2016 20:37:16 +0000 (UTC)

Jim,
I agree with the text except the MUST NOT part. 
There could be services for which these context don't carry any specific meaning, however the forwarding does matter. Why does that particular SF needs to know the schema

    On Wednesday, October 26, 2016 5:28 AM, Jim Guichard (jguichar) <[email-masked]> wrote:

  Dear SFC WG:

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Oct 2016 20:51:12 +0000

Some encapsulations/protocols have a control bit that directs an entity what to do if there are uninterpretable aspects of the data.   That could be a property of the SFP and applied at the classifier – whether to stamp the pass (0) or discard-on-metadata-error (1) bit.   Or, if you wanted to be even more granular, each piece of metadata could carry that bit individually – conceptually both MD-1 and MD-2 could do this.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Wednesday, October 26, 2016 4:37 PM
To: Jim Guichard (jguichar) <[email-masked]>; [email-masked]
Subject: [GRAYMAIL] Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Jim,

On Wednesday, October 26, 2016 5:28 AM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Dear SFC WG:

Jim

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Oct 2016 21:41:11 +0000

Hi Sumandra,

I was pondering the same thing until Med pointed out that the beginning of the sentence says "if an SFC-aware SF is configured to use metadata but does not yet receive the data extraction schema..." so presumably the MUST NOT is dependent upon that and therefore an SF that does not care about the metadata would forward the packet.

Jim

Sent from my iPhone

On Oct 26, 2016, at 4:46 PM, Sumandra Majee <[email-masked]<mailto:[email-masked]>> wrote:

Jim,

Dear SFC WG:

Before asking the editors of the document to make this change, I would like to hear opinions from other WG members so that consensus for this change may be reached. I would particularly like to hear opinions on the last sentence; specifically the 'MUST NOT process' as this implies that an SF must drop a packet if it is unable to process the metadata thereby breaking the chain. Do we need to be this strict or can we simply log an error and forward the packet through the chain?

Jim

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 26 Oct 2016 16:53:42 -0500

Jim,

Yes, exactly, an SF that doesn’t care about the metadata would forward it.
See my earlier email about why an SFC-aware SF that is configured to use
metadata but does not yet have the proper schema must drop the packet.

Cheers,
Andy

On Wed, Oct 26, 2016 at 4:41 PM, Jim Guichard (jguichar) <[email-masked]

> Hi Sumandra,
>
> I was pondering the same thing until Med pointed out that the beginning of
> the sentence says "if an SFC-aware SF is configured to use metadata but
> does not yet receive the data extraction schema..." so presumably the MUST
> NOT is dependent upon that and therefore an SF that does not care about the
> metadata would forward the packet.
>
> Jim
>
> Sent from my iPhone
>
> On Oct 26, 2016, at 4:46 PM, Sumandra Majee <[email-masked]> wrote:
>
> Jim,
>
> There could be services for which these context don't carry any specific
> meaning, however the forwarding does matter. Why does that particular SF
> needs to know the schema
>
>
>
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Oct 2016 21:53:55 +0000

Hi Andy,

Well doesn't it depend upon whether or not the processing of the metadata has an effect on a downstream SF? What if the failing SF is simply logging the application identification whereas all other SFs in the chain don't care about what application it is? Should the forwarding break or should an error simply be logged so that the operator can fix the failing SF?

In other words there are critical and non-critical failures and putting a blanket statement to drop packets if an SF cannot process the metadata seems overkill.

Allowing this to be a local decision with indication of the desired behavior provided by the control plane (who btw is the only one that has knowledge of the whole path) seems more flexible.

Jim

Sent from my iPhone

On Oct 26, 2016, at 12:56 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Jim,

I support this addition. If an SF receives an SFC packet but doesn't have the necessary data extraction schema, how can it properly process the packet?

You also asked whether the packet should be forwarded or dropped at this point. Presumably the chain has been established in a particular order so that the SFs can process the packet in a waterfall process. If one of the SFs cannot process the packet properly, then the waterfall process has been broken, and the packet really should be dropped, since the subsequent SFs in the chain may not have the proper state in place to process the packet, even if they have the schema.

Cheers,
Andy

On Wed, Oct 26, 2016 at 7:28 AM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:
Dear SFC WG:

Jim

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Oct 2016 22:00:30 +0000

Hi Jim,

IMO: It is critical for the WG to make a consensus what to do with MD-1 before publishing this document: 1) NSH protocol specifies MD-1 with 16 bytes context header; 2) this specification specifies MD-1 with 16 bytes context header; the semantics of the context header will be specified in other document. The text we proposed (below) is applicable for 1). If we are open to 2), the text will be different. 2) is saying that the semantics of the context header will be specified later in another document. I don’t think we should open MD-1 for supporting both for sure. If we go with the 1), NSH header is proper text.

BTW: we also suggested to make a single 16 bytes as context header in the figure. I think that the word “mandatory” can be removed. This change applys to both 1) or 2).

This doc. specifies MD-2 as of the form of TLVs, which means that the NSH header conveys both the data semantics and data values. IMO: the doc. needs to specify the additional rules for TLVs and SFC-aware SP implementation. For examples, if an SF does not understand the MD class and/or type when MD-2 presents, what should it do?; if an SF does not find the metadata TLV it expects in the NSH header when MD-2 presents, what does it need to do?; Should the NSH require the individual TLVs to specify how SFs to handle the cases, or NSH can have a rule to apply to all TLVs (I doubt). IMO: this is also important for interworking.

Regards,
Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 26, 2016 2:19 PM
To: [email-masked]
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Dear SFC WG:

Jim

Dear SFC WG:

Jim

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Wed, 26 Oct 2016 22:05:45 +0000

Hello Jim, Sumandra
> so presumably the MUST NOT is dependent upon that and therefore an SF that does not care about the metadata would forward the packet.

If this is the intended meaning, in my opinion it would be useful to add a sentence to clarify/say that. 

Thanks
Roberta  

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 26, 2016 11:41 PM
To: Sumandra Majee <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Sumandra,

Jim

Sent from my iPhone

On Oct 26, 2016, at 4:46 PM, Sumandra Majee <mailto:[email-masked]> wrote:
Jim,

On Wednesday, October 26, 2016 5:28 AM, Jim Guichard (jguichar) <mailto:[email-masked]> wrote:

Dear SFC WG:

Jim

mailto:[email-masked]

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Oct 2016 22:45:18 +0000

Hi Lucy,

I am not following what you mean. The current NSH document specifies MD-type 1 with 4 x 4-byte context headers not a 16-byte context header. It further specifies that the semantics of the context headers is outside the scope of the document.

See section 2.3 bullet 3 which states “The semantics of the shared metadata is communicated via a control plane, which is outside the scope of this document, to participating nodes."

Jim

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 26, 2016 at 6:00 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Jim,

Regards,
Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 26, 2016 2:19 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Dear SFC WG:

Jim

Dear SFC WG:

Jim

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 26 Oct 2016 23:15:01 +0000

Andy,

The metadata is a shared context between certain set of services, not all the services may care about this metadata. If the SF is doing pkt sampling it may not care about any contextual metadata, but it definitely needs to understand the SPI and forwarding rule. Sometimes a service itself could be optional, a video optimizer may not process the video flow at all if it is overloaded.

It is a local decision and I think Dave’s suggestion of making it configurable per service will work fine.

From: sfc <[email-masked]> on behalf of "Andrew G. Malis" <[email-masked]>
Date: Wednesday, October 26, 2016 at 9:56 AM
To: "Jim Guichard (jguichar)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Jim,

I support this addition. If an SF receives an SFC packet but doesn’t have the necessary data extraction schema, how can it properly process the packet?

Cheers,
Andy

Jim

---

From: Lucy yong <[email-masked]>
Date: Thu, 27 Oct 2016 01:02:05 +0000

Hi Jim,

There is no reason to specify 4x4 context headers if the NSH protocol only defines MD-1 as of a 16 bytes context header. This is the change we suggested.

OLD:

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |Ver|O|C|R|R|R|R|R|R|   Length  |  MD type=0x1  | Next Protocol |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |          Service Path Identifer               | Service Index |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Mandatory Context Header                       |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Mandatory Context Header                       |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Mandatory Context Header                       |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Mandatory Context Header                       |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |Ver|O|C|R|R|R|R|R|R|   Length  |  MD type=0x1  | Next Protocol |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |          Service Path Identifer               | Service Index |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Fixed Length Context Header                    |

     |                                                               |

     |                                                               |

     |                                                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 2 is introduction. Section 3 is the NSH protocol specification. Some normative statement should be stated in section 3.

Regards,
Lucy
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, October 26, 2016 5:45 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Lucy,

Jim

Hi Jim,

Regards,
Lucy

Dear SFC WG:

Jim

Dear SFC WG:

Jim

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 27 Oct 2016 02:20:44 +0000 (UTC)

Ok, so if an SF is supposed to understand the metadata but don't have the schema then drop. It really shouldn't happen in practice, it must be an ugly design where it declares yep I have something for you but never delivers. However there could be conflicting schema (again really shouldn't happen).
Perhaps the wording should "if an SFC aware SF is configured to use metadata but doesn't have a unique schema for metadata then it must drop ..." 

    On Wednesday, October 26, 2016 2:41 PM, Jim Guichard (jguichar) <[email-masked]> wrote:

 Hi Sumandra,

Jim,

Dear SFC WG:

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Oct 2016 13:16:51 +0000

So, from the SF’s perspective, it would look something like this, emphasizing the granularity of the metadata schema binding at the SFP level:

SFP ID/Index Expected?                 Metadata schema for SFP ID?                     Action
N                                                         x                                                                         Drop
Y                                                          N                                                                        Drop
Y                                                          Y                                                                         Process Normally

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Wednesday, October 26, 2016 10:21 PM
To: Jim Guichard (jguichar) <[email-masked]>
Cc: [email-masked]
Subject: [GRAYMAIL] Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

On Wednesday, October 26, 2016 2:41 PM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sumandra,

Jim

Sent from my iPhone

Dear SFC WG:

Jim

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 27 Oct 2016 10:53:53 -0500

Jim,

Yes, configurable per service works for me.

Cheers,
Andy

On Wed, Oct 26, 2016 at 6:15 PM, Sumandra Majee <[email-masked]> wrote:

> Andy,
>
>
>
> The metadata is a shared context between certain set of services, not all
> the services may care about this metadata. If the SF is doing pkt sampling
> it may not care about any contextual metadata, but it definitely needs to
> understand the SPI and forwarding rule. Sometimes a service itself could be
> optional, a video optimizer may not process the video flow at all if it is
> overloaded.
>
>
>
> *From: *sfc <[email-masked]> on behalf of "Andrew G. Malis" <
> [email-masked]>
> *Date: *Wednesday, October 26, 2016 at 9:56 AM
> *To: *"Jim Guichard (jguichar)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [sfc] Proposed additional text for section 3.4 of
> draft-ietf-sfc-nsh-10
>
>
>
> Jim,
>
>
>
> On Wed, Oct 26, 2016 at 7:28 AM, Jim Guichard (jguichar) <
> [email-masked]> wrote:
>
> Dear SFC WG:
>
>
>

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Oct 2016 15:55:25 +0000

Andy,

Can you clarify what is meant by “service”?

Thanks.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Thursday, October 27, 2016 11:54 AM
To: Sumandra Majee <[email-masked]>
Cc: Jim Guichard (jguichar) <[email-masked]>; [email-masked]
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Jim,

Cheers,
Andy

On Wed, Oct 26, 2016 at 6:15 PM, Sumandra Majee <[email-masked]<mailto:[email-masked]>> wrote:
Andy,

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 26, 2016 at 9:56 AM
To: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Jim,

Cheers,
Andy

Jim

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 27 Oct 2016 10:58:03 -0500

Ron,

This was in the context of Jim’s email, so what was really meant was
“service function”.

Cheers,
Andy

On Thu, Oct 27, 2016 at 10:55 AM, Ron Parker <
[email-masked]> wrote:

> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Andrew G. Malis
> *Sent:* Thursday, October 27, 2016 11:54 AM
> *To:* Sumandra Majee <[email-masked]>
> *Cc:* Jim Guichard (jguichar) <[email-masked]>; [email-masked]
>
> *Subject:* Re: [sfc] Proposed additional text for section 3.4 of
> draft-ietf-sfc-nsh-10
>
>
>
> Jim,
>
>
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 28 Oct 2016 00:00:48 +0000

Hi Lucy,

The current context header structure has been documented for over 3 years without objection and has already completed WGLC.

There doesn’t seem to be a technical distinction between the proposals, perhaps you could clarify your reasons for a change ?

Jim

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 26, 2016 at 9:02 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Jim,

OLD:

NEW:

     |                                                               |

     |                                                               |

     |                                                               |

Regards,
Lucy
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, October 26, 2016 5:45 PM
To: Lucy yong; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Lucy,

Jim

Hi Jim,

Regards,
Lucy

Dear SFC WG:

Jim

Dear SFC WG:

Jim

---

From: <[email-masked]>
Date: Fri, 28 Oct 2016 09:22:29 +0000

Hi Jim,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 28 octobre 2016 02:01
À : Lucy yong; [email-masked]
Objet : Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Lucy,

The current context header structure has been documented for over 3 years without objection and has already completed WGLC.
[Med] I’m afraid things are more subtle, Jim. The point about the fuzzy design choice of 4 mandatory context headers was raised several times: e.g., https://trac.tools.ietf.org/wg/sfc/trac/ticket/19. I objected the ticket to be closed by the editors here: https://www.ietf.org/mail-archive/web/sfc/current/msg04434.html.

There doesn’t seem to be a technical distinction between the proposals, perhaps you could clarify your reasons for a change ?
[Med] The rationale is as follows:

·         Given that the semantic is defined elsewhere and no specific syntax validation are in the NSH spec, it does not make sense to impose the boundaries inside the 16 bytes block.

·         Defining the semantic of each 4-byte context header would be achieved by allowing to define the semantic of the 16bytes block as a whole.

·         The specification of the context header will be simplified.

o    Let’s consider the example in https://tools.ietf.org/html/draft-kumar-sfc-offloads-03:

      |D| F |X|         Context Header 1                              |

      |B|U|T|D|R|R|R|R| Context Header 2                              |

      |                 Context Header 3                              |

      |                 Context Header 4                              |

   X : Extend flags into first byte of "Context Header 2"

   B : Bidirectional Offload

   U : Unidirectional Offload

   T : TCP-control Exception Offload

   D : Drop Offload

   An X flag is defined because of these boundaries!! These same set of flags are aligned without any constraint for MD#2.

      |B|U|T|D|S|V|R|R|R|R|R|R|         Offload-data                  |

o    Let’s now consider the example in https://tools.ietf.org/html/draft-napper-sfc-nsh-broadband-allocation-01#section-4.1. With the 16bytes block, you don’t need to overload the reader with the CHi terminology:

OLD:
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | R | Sub | Tag |                 Context ID                    | CH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sub/Endpoint ID                         ~ CH2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   Sub/Endpoint ID (cont.)                     | CH3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Service Information                        | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: NSH Context Allocation

NEW:

   | R | Sub | Tag |                 Context ID                    |

   |                       Sub/Endpoint ID                         |

   |                                                               |

   |                    Service Information                        |

                     Figure 3: NSH Context Allocation

·         In the absence of technical justification for the presence of the boundaries between 4byte headers, I suggest to go for a single 16bytes block.

Jim

Hi Jim,

OLD:

NEW:

     |                                                               |

     |                                                               |

     |                                                               |

Regards,
Lucy

Hi Lucy,

Jim

Hi Jim,

Regards,
Lucy

Dear SFC WG:

Jim

Dear SFC WG:

Jim

---

From: Ron Parker <[email-masked]>
Date: Fri, 28 Oct 2016 13:55:01 +0000

Mohamed,

As a group, we’ve more or less accepted that the format of the MD-1 metadata is opaque and non-self describing.   For those that don’t like that, MD type 2 was the grand compromise.

Therefore, I wholeheartedly agree that imposing internal structure to MD-1 metadata is counter--productive.    There are 16 mandatory bytes whose use is described in other RFPs or not described at all.   Whether any particular usage imposes internal 4 byte boundaries or not is irrelevant since it is opaque, by definition.    Given the opaque and non-self-describing decisions, I strongly support modification of the NSH RFP to describe the MD-type 1 metadata as a single 16 byte opaque block of metadata instead of 4 4-byte context headers.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, October 28, 2016 5:22 AM
To: Jim Guichard (jguichar) <[email-masked]>; Lucy yong <[email-masked]>; [email-masked]
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Jim,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 28 octobre 2016 02:01
À : Lucy yong; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Lucy,

      |                 Context Header 3                              |

      |                 Context Header 4                              |

   D : Drop Offload

OLD:

NEW:

   |                       Sub/Endpoint ID                         |

   |                                                               |

   |                    Service Information                        |

Jim

Hi Jim,

OLD:

NEW:

     |                                                               |

     |                                                               |

     |                                                               |

Regards,
Lucy

Hi Lucy,

Jim

Hi Jim,

Regards,
Lucy

Dear SFC WG:

Jim

Dear SFC WG:

Jim

---

From: Dave Dolson <[email-masked]>
Date: Fri, 28 Oct 2016 14:31:55 +0000

I agree it is better to document the MD-type 1 as a 16-byte opaque block.

-          The proposed allocations (dc, broadband, ns) seem to be more encumbered by the 4-byte boundaries than benefiting from them.

-          There is no impact to forwarding behavior by changing how the 16 bytes are documented.

-          When MD-Type=1, there needs to be out-of-band agreement on what the 16 bytes mean, so making 4 artificial opaque fields is more confusing than a single 16-byte opaque field.

Also, as Med says, there have been many questions and objections to the MD-type 1 format on the list. I don’t think it’s accurate to say it has been documented for 3 years without objection.

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Friday, October 28, 2016 9:55 AM
To: [email-masked]; Jim Guichard (jguichar); Lucy yong; [email-masked]
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Mohamed,

   Ron

Hi Jim,

Please see inline.

Cheers,
Med

Hi Lucy,

      |                 Context Header 3                              |

      |                 Context Header 4                              |

   D : Drop Offload

OLD:

NEW:

   |                       Sub/Endpoint ID                         |

   |                                                               |

   |                    Service Information                        |

Jim

Hi Jim,

OLD:

NEW:

     |                                                               |

     |                                                               |

     |                                                               |

Regards,
Lucy

Hi Lucy,

Jim

Hi Jim,

Regards,
Lucy

Dear SFC WG:

Jim

Dear SFC WG:

Jim

---

From: Lucy yong <[email-masked]>
Date: Fri, 28 Oct 2016 14:34:25 +0000

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Thursday, October 27, 2016 7:01 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Lucy,

The current context header structure has been documented for over 3 years without objection and has already completed WGLC.
[Lucy] But there are open issues and people brought this up again in the recent interim meeting.

There doesn’t seem to be a technical distinction between the proposals, perhaps you could clarify your reasons for a change ?
[Lucy] Current text in section 3.4 does not say much (that causes the concern). The new expression is more precise and will make the additional text for the section easier.

“Context Headers that carry no metadata MUST be set to zero.” Is not right for MD-1 because NSH does not make any assumption on the metadata on the context header. If SFC does not requirement many metadata, MD-type value MUST be set to zero. We should reserve value of zero  for no metadata.

Thanks,
Lucy

Jim

Hi Jim,

OLD:

NEW:

     |                                                               |

     |                                                               |

     |                                                               |

Regards,
Lucy

Hi Lucy,

Jim

Hi Jim,

Regards,
Lucy

Dear SFC WG:

Jim

Dear SFC WG:

Jim