Subject: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 7 Aug 2014 08:20:24 -0400

Carlos and Joel,

In light of the previous discussions, I went back and re-read this current
definition of SFC Encapsulation in the text (section 1.3):

   SFC Encapsulation:  The SFC Encapsulation provides at a minimum SFP
        identification, and is used by the SFC-aware functions, such as
        the SFF and SFC-aware SFs.  The SFC Encapsulation is not used
        for network packet forwarding.  In addition to SFP
        identification, the SFC encapsulation carries dataplane context
        information, also referred to as metadata.

I think this could be tightened up to make simpler for the reader:

SFC Encapsulation:  A data plane encapsulation that identifies the SFP
and/or provides metadata (data plane context information). The SFP
Encapsulation is used by the SFC-aware functions, such as the SFF and
SFC-aware SFs, and is not used for network packet forwarding.

Thanks,
Andy

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 7 Aug 2014 12:51:07 +0000

Thank you for going back and checking, Andy!

Which specific part of the current definition do you believe is loose enough to need tightening?

I believe that your new proposal falls shorter than the existing text in a few areas:

  *   First, it combines two different functions (SFP identification and metadata/context information) into a single sentence. This opposes the change we just made based on your preference in Section 4.1, which breaks the two functions into two sentences, for reader clarity. While longer, it's simpler.
  *   Second, it introduces an extraneous "and/or" that would change the meaning, and negate the "at a minimum" existing bit. That would not be simplifying.
  *   Third, there is no third but three bullets look better :-)

Net-net, the original text, even when longer in character count, seems more clear and simpler to the reader (because of the separated sentences), IMHO.

Thanks,

Carlos.

On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Carlos and Joel,

In light of the previous discussions, I went back and re-read this current definition of SFC Encapsulation in the text (section 1.3):

SFC Encapsulation:  A data plane encapsulation that identifies the SFP and/or provides metadata (data plane context information). The SFP Encapsulation is used by the SFC-aware functions, such as the SFF and SFC-aware SFs, and is not used for network packet forwarding.

Thanks,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 7 Aug 2014 09:06:03 -0400

Carlos,

When I re-read the definition, it seemed to me to be more of a string of
thoughts than a concise definition, which is why I was trying to tighten it
up. A definition is meant to be a short summary for quick reference, while
the discussion in 4.1 goes into the more formal details.  Otherwise, you
would just repeat the entire section 4.1 in section 1.3.  This is why it
doesn't need to be in separate sentences. The "and/or" is because not every
usage of the encapsulation will need both the SFP identification and the
metadata, so the definition needs to concisely convey that.

Cheers,
Andy

On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>    - First, it combines two different functions (SFP identification and
>    metadata/context information) into a single sentence. This opposes the
>    change we just made based on your preference in Section 4.1, which breaks
>    the two functions into two sentences, for reader clarity. While longer,
>    it's simpler.
>    - Second, it introduces an extraneous "and/or" that would change the
>    meaning, and negate the "at a minimum" existing bit. That would not be
>    simplifying.
>    - Third, there is no third but three bullets look better :-)
>
>
>  Net-net, the original text, even when longer in character count, seems
> more clear and simpler to the reader (because of the separated sentences),
> IMHO.
>
>  Thanks,
>
>  Carlos.
>
>  On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <[email-masked]> wrote:
>
>  Carlos and Joel,
>
>  In light of the previous discussions, I went back and re-read this
> current definition of SFC Encapsulation in the text (section 1.3):
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 7 Aug 2014 15:09:06 +0000

I like the text Andy proposed for SFC encapsulation definition. It is concise and clear.
Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Thursday, August 07, 2014 8:06 AM
To: Carlos Pignataro (cpignata)
Cc: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

Carlos,

When I re-read the definition, it seemed to me to be more of a string of thoughts than a concise definition, which is why I was trying to tighten it up. A definition is meant to be a short summary for quick reference, while the discussion in 4.1 goes into the more formal details.  Otherwise, you would just repeat the entire section 4.1 in section 1.3.  This is why it doesn't need to be in separate sentences. The "and/or" is because not every usage of the encapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that.

Cheers,
Andy

On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for going back and checking, Andy!

Thanks,

Carlos.

Carlos and Joel,

Thanks,
Andy

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 8 Aug 2014 01:13:23 +0000

I fully agree with Andy’s point that not every usage of the encapsulation will need both the SFP identification and the metadata. It’s better that the SFC encapsulation could be flexibly used for carrying SFP identification, metadata or both. Otherwise, it seems that those SFC approaches which don’t use the SFC encapsulation for SFC selection would have to separately define the way of carrying metadata.

Best regards,
Xiaohu 

Sent: Thursday, August 07, 2014 9:06 PM

Carlos,

Cheers,
Andy

On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
Thank you for going back and checking, Andy! 

I believe that your new proposal falls shorter than the existing text in a few areas:
• First, it combines two different functions (SFP identification and metadata/context information) into a single sentence. This opposes the change we just made based on your preference in Section 4.1, which breaks the two functions into two sentences, for reader clarity. While longer, it's simpler.
• Second, it introduces an extraneous "and/or" that would change the meaning, and negate the "at a minimum" existing bit. That would not be simplifying.
• Third, there is no third but three bullets look better :-)

Thanks,

Carlos.

Carlos and Joel, 

Thanks,
Andy

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Fri, 8 Aug 2014 12:53:01 +0000

I agree that we should have stronger separation of two functions: SFP and metadata. 

How about small edit to what Andy proposed:

SFC Encapsulation:  A data plane encapsulation that encodes either one or both of
- the SFP 
- metadata (data plane context information). 
> The SFP Encapsulation is used by the SFC-aware functions, such as the SFF and SFC-aware SFs, and is not used for network packet forwarding.

Andrew

Sent from my iPhone

> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <[email-masked]> wrote:
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 8 Aug 2014 09:19:36 -0400

Andrew,

That looks great to me.

Cheers,
Andy

On Fri, Aug 8, 2014 at 8:53 AM, Dolganow, Andrew (Andrew) <
[email-masked]> wrote:

> > The SFP Encapsulation is used by the SFC-aware functions, such as the
> SFF and SFC-aware SFs, and is not used for network packet forwarding.
>
>
> Andrew
>
> Sent from my iPhone
>
> > I fully agree with Andy’s point that not every usage of the
> encapsulation will need both the SFP identification and the metadata. It’s
> better that the SFC encapsulation could be flexibly used for carrying SFP
> identification, metadata or both. Otherwise, it seems that those SFC
> approaches which don’t use the SFC encapsulation for SFC selection would
> have to separately define the way of carrying metadata.
> >
> > Best regards,
> > Xiaohu
> >
> > • First, it combines two different functions (SFP identification and
> > • Second, it introduces an extraneous "and/or" that would change the

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 8 Aug 2014 15:06:18 +0000

Hi, Xiaohu, Andy, Lucy,

I agree Andy with the goal of a simple definition. From a "simplifying to the reader" perspective, two smaller sentences are easier to parse than an concatenated mega-sentence. And if you consider all the definitions in Section 1.3, the one for "SFC Encapsulation" is within the shortest ones, and to me follows a logical succession of sentences instead of a stream of thoughts. That said, if the definition needs tightening let's do so maintaining the meaning. Again, the meaning is constrained by and needs to follow the charter, which is not "and/or".

Thanks,

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 8 Aug 2014 15:09:13 +0000

Hi, Andrew,

> - metadata (data plane context information). 

Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either one or both of". In fact, looking at the history of the charter text, the text for SFC Encapsulation is a bullet list form of a longer sentence that includes "and" only (see 00-09).

Thanks,

Carlos.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 8 Aug 2014 17:46:37 -0400

Carlos,

I agree that the charter requires the encapsulation to support each of the
bullet items, but there's no requirement that every encapsulated packet
will need all of the bullet items supported, so I'm trying to keep the text
as flexible as possible to not preclude possible solutions.

Cheers,
Andy

On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Hi, Andrew,
>
> On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <
> Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no
> "either one or both of". In fact, looking at the history of the charter
> text, the text for SFC Encapsulation is a bullet list form of a longer
> sentence that includes "and" only (see 00-09).
>
> Thanks,
>
> Carlos.
>
> >> When I re-read the definition, it seemed to me to be more of a string
> of thoughts than a concise definition, which is why I was trying to tighten
> it up. A definition is meant to be a short summary for quick reference,
> while the discussion in 4.1 goes into the more formal details.  Otherwise,
> you would just repeat the entire section 4.1 in section 1.3.  This is why
> it doesn't need to be in separate sentences. The "and/or" is because not
> every usage of the encapsulation will need both the SFP identification and
> the metadata, so the definition needs to concisely convey that.
> >>
> >> Cheers,
> >> Andy
> >>

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Sat, 9 Aug 2014 12:52:17 +0000

Agree with Andy.

Andrew

Sent from my iPhone

On Aug 8, 2014, at 5:47 PM, "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

I agree that the charter requires the encapsulation to support each of the bullet items, but there's no requirement that every encapsulated packet will need all of the bullet items supported, so I'm trying to keep the text as flexible as possible to not preclude possible solutions.

Cheers,
Andy

On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Andrew,

Thanks,

Carlos.

>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew G. Malis
>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

---

From: Lucy yong <[email-masked]>
Date: Mon, 11 Aug 2014 14:47:15 +0000

I agree Andy’s point.

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Friday, August 08, 2014 4:47 PM
To: Carlos Pignataro (cpignata)
Cc: Xuxiaohu; Dolganow, Andrew (Andrew); [email-masked]; Joel M. Halpern
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

Carlos,

Cheers,
Andy

Thanks,

Carlos.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 11 Aug 2014 16:05:20 +0000

Same here, I believe these elements should be independent.

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Monday 11 August 2014 16:47
To: "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Cc: Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "Dolganow, Andrew (Andrew)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

I agree Andy’s point.

Lucy

Cc: Xuxiaohu; Dolganow, Andrew (Andrew); [email-masked]<mailto:[email-masked]>; Joel M. Halpern

Carlos,

Cheers,
Andy

Thanks,

Carlos.

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Tue, 12 Aug 2014 08:26:23 +0000

Hi Carlos and all,

Since the design goal is to allow SFC being an overlay of any network, it make sense to have a generic data plane encapsulation encodes the SFP. Meanwhile, communication between SFs, where metadata is used, may be required in certain scenarios but not all cases, so, metadata should be optionally encapsulated.

Cheers,
Hongyu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, August 08, 2014 11:09 PM
To: Dolganow, Andrew (Andrew)
Cc: Xuxiaohu; Joel M. Halpern; Andrew G. Malis; [email-masked]
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

Hi, Andrew,

Thanks,

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 13 Aug 2014 01:51:45 +0000

Hi, Andy, Lucy,

Flexibility is certainly good as long as it does not get in the way of interoperability. This architecture drives a balance and tradeoff in which options are maximized while having interoperability as the goal.

>From a technical perspective, the SFC Encapsulation specifies the Service Function Path to allow for end-to-end SFPs and interoperable implementations. One of the key principles of this architecture is that the SFC Encapsulation is transport-independent. The text is flexible such that any transport may be used to carry the SFC encapsulation. However, two SFs part of an SFP that are not adjacent in the services topology can have different transport encapsulations but need the SFC-encapsulation (minimum invariant encap) to specify the SPF. This is within the service topology, which again is independent from the underlay topology as an architectural principle. Please note that the use of the SFC encapsulation to specify the SFP and the SFFs and SFs use of this is articulated throughout the architecture. This architecture also allows for flexibility in bringing SFC-unaware SFs by proxy as the one gateway, to provide backwards compatibility, but attempts to carry forward interoperability. Consequently, for "SFC Aware" chains, the architectural choice that follows the principles is to carry the SFP id. It is (also) to convey shared context (when demanded by the use case) using the SFC-encapsulation for similar reasons. As a WG, I believe we should first strive for a single service-level data plane encapsulation as per the current WG charter and based on that provide the most optimal placement of functions and identifiers.

Note also that I was pointing to the charter because I believe these points were discussed already to get to the current charter text.

Best,

Carlos.

On Aug 11, 2014, at 10:47 AM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:

I agree Andy’s point.

Lucy

Carlos,

Cheers,
Andy

Thanks,

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 13 Aug 2014 01:51:50 +0000

Hi, Hongyu,

I see this a very similar way.

Thanks,

-- Carlos.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 13 Aug 2014 09:47:53 -0400

Carlos,

I see your point, but there's also been discussion of cases where only the
metadata is required. In that case, you woud either be carrying a null SFP
ID along with the metadata, or just the metadata. It seems more efficient
to me to just carry the metadata, but if you want to insist that there's
always an SPF ID, then we need to make sure that it can be a null ID.

Cheers,
Andy

On Tue, Aug 12, 2014 at 9:51 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>  Hi, Andy, Lucy,
>
>  Flexibility is certainly good as long as it does not get in the way of
> interoperability. This architecture drives a balance and tradeoff in which
> options are maximized while having interoperability as the goal.
>
>  From a technical perspective, the SFC Encapsulation specifies the
> Service Function Path to allow for end-to-end SFPs and interoperable
> implementations. One of the key principles of this architecture is that the
> SFC Encapsulation is transport-independent. The text is flexible such that
> any transport may be used to carry the SFC encapsulation. However, two SFs
> part of an SFP that are not adjacent in the services topology can have
> different transport encapsulations but need the SFC-encapsulation (minimum
> invariant encap) to specify the SPF. This is within the service topology,
> which again is independent from the underlay topology as an architectural
> principle. Please note that the use of the SFC encapsulation to specify the
> SFP and the SFFs and SFs use of this is articulated throughout the
> architecture. This architecture also allows for flexibility in bringing
> SFC-unaware SFs by proxy as the one gateway, to provide backwards
> compatibility, but attempts to carry forward interoperability.
> Consequently, for "SFC Aware" chains, the architectural choice that follows
> the principles is to carry the SFP id. It is (also) to convey shared
> context (when demanded by the use case) using the SFC-encapsulation for
> similar reasons. As a WG, I believe we should first strive for a
> single service-level data plane encapsulation as per the current WG charter
> and based on that provide the most optimal placement of functions and
> identifiers.
>
>  Note also that I was pointing to the charter because I believe these
> points were discussed already to get to the current charter text.
>
>  Best,
>
>  Carlos.
>
>  On Aug 11, 2014, at 10:47 AM, Lucy yong <[email-masked]> wrote:
>
>   I agree Andy’s point.
>
>  Lucy
>
>  *From:* sfc [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Andrew G. Malis
> *Sent:* Friday, August 08, 2014 4:47 PM
> *To:* Carlos Pignataro (cpignata)
> *Cc:* Xuxiaohu; Dolganow, Andrew (Andrew); [email-masked]; Joel M. Halpern
> *Subject:* Re: [sfc] Definition of SFC Encapsulation in
> draft-merged-sfc-architecture-01.txt
>
>  Carlos,
>
>   I agree that the charter requires the encapsulation to support each of
> the bullet items, but there's no requirement that every encapsulated packet

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 13 Aug 2014 17:37:42 +0000

I agree with Andy that the case of carrying only metadata needs to be considered. Actually our service chain header draft already takes this into consideration. The proposal in the service chain header draft is to carry metadata and set SPF ID to be NULL. Here is a snip of the draft:

   The SCH may be used to carry: (1) both SFC path steering information
   and metadata; (2) only SFC path steering information, in which case
   the Metadata Length field shall be set to zero; or (3) only metadata,
   in which case the Path Identifier and SF Index fields shall be set to
   zero for transmit and ignored upon receipt.

Thanks,
Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Wednesday, August 13, 2014 6:48 AM
To: Carlos Pignataro (cpignata)
Cc: Xuxiaohu; Dolganow, Andrew (Andrew); [email-masked]; Lucy yong; Joel M. Halpern
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

Carlos,

I see your point, but there's also been discussion of cases where only the metadata is required. In that case, you woud either be carrying a null SFP ID along with the metadata, or just the metadata. It seems more efficient to me to just carry the metadata, but if you want to insist that there's always an SPF ID, then we need to make sure that it can be a null ID.

Cheers,
Andy

On Tue, Aug 12, 2014 at 9:51 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Andy, Lucy,

Best,

Carlos.

I agree Andy’s point.

Lucy

Carlos,

Cheers,
Andy

Thanks,

Carlos.

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Thu, 14 Aug 2014 04:01:26 +0000

Hi all,

I noticed there were some discussion that SFP ID could be null or zero. However, there wes not any persuasive use case or scenario provided so far. In case of expecting interoperability with legacy devices, an existing protocol is needed, meaning carrying metadata with such a protocol is not possible either, as any modification to the protocol will lead to modification of legacy devices.

If SFP ID is null or zero, how could you find the next hop in each SFF? Where is the SFC/SFP layer?

Cheers,
Hongyu

From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Thursday, August 14, 2014 1:38 AM
To: Andrew G. Malis; Carlos Pignataro (cpignata)
Cc: Xuxiaohu; Dolganow, Andrew (Andrew); Lucy yong; [email-masked]; Joel M. Halpern
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

Thanks,
Cathy

Cc: Xuxiaohu; Dolganow, Andrew (Andrew); [email-masked]<mailto:[email-masked]>; Lucy yong; Joel M. Halpern

Carlos,

Cheers,
Andy

Best,

Carlos.

I agree Andy’s point.

Lucy

Carlos,

Cheers,
Andy

Thanks,

Carlos.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 14 Aug 2014 07:07:34 -0400

I would think an SFF receiving an SFP ID value of zero would interpret 
it to mean that there is no next hop.

Tom Taylor

On 14/08/2014 12:01 AM, Hongyu Li (Julio) wrote:
> Hi all,
>
> I noticed there were some discussion that SFP ID could be null or
> zero. However, there wes not any persuasive use case or scenario
> provided so far. In case of expecting interoperability with legacy
> devices, an existing protocol is needed, meaning carrying metadata
> with such a protocol is not possible either, as any modification to
> the protocol will lead to modification of legacy devices.
>
...

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 14 Aug 2014 15:40:36 +0000

Hi, Andy,

Thanks for the response -- from an architecture perspective, what I think is important to capture is that the SFC Encapsulation carries the specification of the Service Function Path. I believe that the specifics of how that happens in the SFP ID belongs in the encapsulation document. But architecturally we want to capture that the SFC encapsulation specifies the SFP and have a clean and simple architecture independent of transports and underlying topologies.

Now, separately from this specific discussion, you do mention discussion of specific cases and a potential encap value for that. Could you share some more specifics? This would be useful for the discussion of the encapsulation WG deliverable. Xiaohu shared two pointers to two individual I-Ds, and it seems (again, not an architectural comment but jumping ahead) that a null SPF ID would not make those cases interoperate. Does that call for a per-transport solution against the charter? Looking at the draft-ietf-sfc-problem-statement, specifically Sections 2.1 and 2.6, the reason why SFC exists is to provide that transport and topological independence as opposed to existing (transport dependent) ways of chaining network services.

Thanks,

Carlos.

On Aug 13, 2014, at 9:47 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

Cheers,
Andy

Best,

Carlos.

I agree Andy¹s point.

Lucy

Carlos,

Cheers,
Andy

Thanks,

Carlos.

>> I fully agree with Andy¹s point that not every usage of the encapsulation will need both the SFP identification and the metadata. It¹s better that the SFC encapsulation could be flexibly used for carrying SFP identification, metadata or both. Otherwise, it seems that those SFC approaches which don¹t use the SFC encapsulation for SFC selection would have to separately define the way of carrying metadata.
>>
>> Best regards,
>> Xiaohu
>>
>> € First, it combines two different functions (SFP identification and metadata/context information) into a single sentence. This opposes the change we just made based on your preference in Section 4.1, which breaks the two functions into two sentences, for reader clarity. While longer, it's simpler.
>> € Second, it introduces an extraneous "and/or" that would change the meaning, and negate the "at a minimum" existing bit. That would not be simplifying.
>> € Third, there is no third but three bullets look better :-)
>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 15 Aug 2014 09:24:34 -0400

Carlos,

Our goal as a WG should be to design the SFC encapsulation is to allow
flexibility and wide use in different use case and implementation
scenarios. Another practical goal should be encapsulation compactness to
the greatest extent possible to avoid packet MTU and fragmentation issues.
One scenario/use case that has been discussed is the use of a control plane
to install state such that just the metadata (or even just packet
header/data) is all that's required to forward packets on the proper path.
So for this case, we should be able to have a nonexistent or very compact
null value for the SFP ID.

Thanks,,
Andy

On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>  Hi, Andy,
>
>  Thanks for the response -- from an architecture perspective, what I
> think is important to capture is that the SFC Encapsulation carries the
> specification of the Service Function Path. I believe that the specifics of
> how that happens in the SFP ID belongs in the encapsulation document. But
> architecturally we want to capture that the SFC encapsulation specifies the
> SFP and have a clean and simple architecture independent of transports and
> underlying topologies.
>
>  Now, separately from this specific discussion, you do mention discussion
> of specific cases and a potential encap value for that. Could you share
> some more specifics? This would be useful for the discussion of the
> encapsulation WG deliverable. Xiaohu shared two pointers to two individual
> I-Ds, and it seems (again, not an architectural comment but jumping ahead)
> that a null SPF ID would not make those cases interoperate. Does that call
> for a per-transport solution against the charter? Looking at
> the draft-ietf-sfc-problem-statement, specifically Sections 2.1 and 2.6,
> the reason why SFC exists is to provide that transport and topological
> independence as opposed to existing (transport dependent) ways of chaining
> network services.
>
>  Thanks,
>
>  Carlos.
>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Aug 2014 10:43:49 -0400

I would have phrased the goal you state as one where we want to enable 
such data forwarding.  But we want such data forwarding to interoperate 
with other modes.  You don't even list interoperability in there.  And 
that is the primary goal for IETF work.

Yours,
Joel

On 8/15/14, 9:24 AM, Andrew G. Malis wrote:
> the greatest extent possible to avoid packet MTU and fragmentation
> issues. One scenario/use case that has been discussed is the use of a
> control plane to install state such that just the metadata (or even just
> packet header/data) is all that's required to forward packets on the
> proper path. So for this case, we should be able to have a nonexistent
> or very compact null value for the SFP ID.
>
> Thanks,,
> Andy
>
>
>
> On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignataro (cpignata)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi, Andy,
>
>     think is important to capture is that the SFC Encapsulation carries
>     the specification of the Service Function Path. I believe that the
>     specifics of how that happens in the SFP ID belongs in the
>     encapsulation document. But architecturally we want to capture that
>     the SFC encapsulation specifies the SFP and have a clean and simple
>     architecture independent of transports and underlying topologies.
>
>     Now, separately from this specific discussion, you do mention
>     discussion of specific cases and a potential encap value for that.
>     Could you share some more specifics? This would be useful for the
>     discussion of the encapsulation WG deliverable. Xiaohu shared two
>     pointers to two individual I-Ds, and it seems (again, not an
>     architectural comment but jumping ahead) that a null SPF ID would
>     not make those cases interoperate. Does that call for a
>     per-transport solution against the charter? Looking at
>     the draft-ietf-sfc-problem-statement, specifically Sections 2.1 and
>     2.6, the reason why SFC exists is to provide that transport and
>     topological independence as opposed to existing (transport
>     dependent) ways of chaining network services.
>
>     Thanks,
>
>     Carlos.
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 15 Aug 2014 11:35:39 -0400

Joel,

Sorry, I was taking interoperability as a given, of course that's required.
But interoperability isn't the only goal, flexibility and efficiency should
be goals as well.

Cheers,
Andy

On Fri, Aug 15, 2014 at 10:43 AM, Joel M. Halpern <[email-masked]>
wrote:

> with other modes.  You don't even list interoperability in there.  And that
> is the primary goal for IETF work.
>
> Yours,
> Joel
>
>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Fri, 15 Aug 2014 16:14:22 +0000

The variability of the offset has a cost in performance just as the length will inevitably cause concerns about the MTU.

>From a practical perspective, how many service chains will actually traverse spaces outside of a walled garden or a macro space where a single operator is in control (personally or as a proxy, as in cell site backhaul)?  In those cases, can't the normal concerns over the MTU can be mitigated operationally by supporting jumbo packets or turning on PMTUD (assuming you set up the right filters to avoid outside-the-domain-PMTDU attacks) …outside of those scenarios (multi-domain), you have a valid concern …but are they the minority or majority case?

From: "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 15, 2014 9:24 AM
To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Cc: Xiaohu Xu <[email-masked]<mailto:[email-masked]>>, "Dolganow, Andrew (Andrew)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

Carlos,

Our goal as a WG should be to design the SFC encapsulation is to allow flexibility and wide use in different use case and implementation scenarios. Another practical goal should be encapsulation compactness to the greatest extent possible to avoid packet MTU and fragmentation issues. One scenario/use case that has been discussed is the use of a control plane to install state such that just the metadata (or even just packet header/data) is all that's required to forward packets on the proper path. So for this case, we should be able to have a nonexistent or very compact null value for the SFP ID.

Thanks,,
Andy

On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Andy,

Thanks,

Carlos.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 16 Aug 2014 13:31:59 -0400

Ken,

I agree, there are always tradeoffs to consider. We don't yet know the
answers to the questions in your email. However, at some point, the WG will
need to come to agreement on a specific SFC encapsulation. So right now, I
just think it's prudent to keep the architecture document as flexible as
possible so that it doesn't preclude any particular alternatives when it
comes time for the WG to come to agreement on the encapsulation.

Cheers,
Andy

On Fri, Aug 15, 2014 at 12:14 PM, Ken Gray (kegray) <[email-masked]>
wrote:

>  The variability of the offset has a cost in performance just as the
> length will inevitably cause concerns about the MTU.
>
>  From a practical perspective, how many service chains will actually
> traverse spaces outside of a walled garden or a macro space where a single
> operator is in control (personally or as a proxy, as in cell site
> backhaul)?  In those cases, can't the normal concerns over the MTU can be
> mitigated operationally by supporting jumbo packets or turning on PMTUD
> (assuming you set up the right filters to avoid outside-the-domain-PMTDU
> attacks) …outside of those scenarios (multi-domain), you have a valid
> concern …but are they the minority or majority case?
>
>

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Mon, 18 Aug 2014 18:31:30 +0000

Andy, Carlos, Lucy

We should be careful how much overhead we introduce to implement various options. Although NULL ID would satisfy the requirement we have, I would prefer we support metadata withoutSPF ID (there are bits we can use to indicate no SPF presence).

Andrew

On 2014-08-13, 9:47 AM, "Andrew G. Malis" wrote:

Carlos,

Cheers,
Andy

Best,

Carlos.

I agree Andy’s point.

Lucy

Carlos,

Cheers,
Andy

Thanks,

Carlos.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 21 Aug 2014 03:03:37 +0000

Hi Carlos,

Please see my comment inline.

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Thursday, August 14, 2014 11:41 PM
To: Andrew G. Malis
Cc: Lucy yong; Xuxiaohu; Dolganow, Andrew (Andrew); [email-masked]; Joel M. Halpern
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt

Hi, Andy,

[Xiaohu] In fact, the MPLS-SPRING-based SFC approach fully meets the transport-independent requirement of SFC.  The underlay (a.k.a. transport) could be IP, MPLS or even Ethernet network. It just happened that the MPLS technology which had been widely deemed as a transport technology is now used as the service function overlay (i.e., encoding the SFC or the SFP information by an MPLS label stack).

Best Regards,
Xiaohu

Thanks,

Carlos.

Carlos,

Cheers,
Andy

Best,

Carlos.

I agree Andy¹s point.

Lucy

Carlos,

Cheers,
Andy

Thanks,

Carlos.