Subject: [sfc] is current SFC architecture supporting different types of SFC header formats?

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 4 Dec 2014 10:17:28 +0000

Hi all,

Please note that I was reviewing the SFC architecture draft, see below, and I have a question:
http://www.ietf.org/id/draft-ietf-sfc-architecture-02.txt

Can you please let me know if the current version of the SFC architecture 
allows the use of different Service Function Chaining Header formats?

These formats and their analysis can be found in Section 5 of the following draft:

http://www.ietf.org/id/draft-boucadair-sfc-design-analysis-03.txt

If that is not the case, please elaborate why.

Best regards,
Georgios

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 4 Dec 2014 13:46:11 +0000

Hi, Georgios,

The SFC architecture document concerns itself with the functions and not the format.

Thanks,

Carlos.

> On Dec 4, 2014, at 5:17 AM, Georgios Karagiannis <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 4 Dec 2014 13:55:34 +0000

Hi Carlos,

Thanks for your answer!

Does this mean that the SFC architecture is allowing the use of different Service Function Chaining Header (SFC encapsulation) formats?

I am referring to the different SFC encapsulation formats that are discussed in section 5 of the following ID:
http://www.ietf.org/id/draft-boucadair-sfc-design-analysis-03.txt

Best regards,
Georgios

> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: Thursday, December 04, 2014 2:46 PM
> To: Georgios Karagiannis
> Cc: [email-masked]
> Subject: Re: [sfc] is current SFC architecture supporting different types of
> SFC header formats?
> 
> Hi, Georgios,
> 
> > Can you please let me know if the current version of the SFC
> > architecture allows the use of different Service Function Chaining Header
> formats?
> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 4 Dec 2014 14:01:38 +0000

Hi, Georgios,

Do you mean different SFC Encapsulations simultaneously? The SFC charter
says:

<snip>
3. Generic SFC Encapsulation: This document will describe a single
   service-level data plane encapsulation format that:

</snip>

Because interoperability is the goal.

Looking at that section, the terminology does not seem to align to the
arch and problem-statement documents. Also, that section seems to describe
a pseudo-format, not a format. The architecture describes the functions in
Section 4.1 and other places.

Thanks,

Carlos.

On 12/4/14, 8:55 AM, "Georgios Karagiannis"
<[email-masked]> wrote:

>Hi Carlos,
>
>Thanks for your answer!
>
>Does this mean that the SFC architecture is allowing the use of different
>Service Function Chaining Header (SFC encapsulation) formats?
>
>I am referring to the different SFC encapsulation formats that are
>discussed in section 5 of the following ID:
>> The SFC architecture document concerns itself with the functions and
>>not the
>> format.
>> 
>> Thanks,
>> 
>> Carlos.
>> 
>> > Please note that I was reviewing the SFC architecture draft, see
>>below, and
>> I have a question:
>> > These formats and their analysis can be found in Section 5 of the
>>following
>> draft:
>> >

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 4 Dec 2014 14:40:38 +0000

Hi Carlos,

Please note that I do not mean to use different SFC encapsulations simultaneously.

>From what I understood from IETF'91 meeting discussions, the Generic SFC encapsulation technique has not yet been selected by the SFC WG.

I think that this means that the SFC architecture draft cannot be in favor for one specific 
SFC encapsulation technique and at the same time excluding other techniques.

My question is: 

Can the following two SFC encapsulation techniques be supported by the functions described in the SFC architecture draft?:

o) Single Marking Code Point, like format, see section 5.1 on boucadair draft, see below.

o) Explicit Route List, like format, see section 5.3 on boucadair draft, see below.

Best regards,
Georgios

> Sent: Thursday, December 04, 2014 3:02 PM
> To: Georgios Karagiannis
> Cc: [email-masked]
> Looking at that section, the terminology does not seem to align to the arch
> and problem-statement documents. Also, that section seems to describe a
> pseudo-format, not a format. The architecture describes the functions in
> >Does this mean that the SFC architecture is allowing the use of
> >different Service Function Chaining Header (SFC encapsulation) formats?
> >
> >> Subject: Re: [sfc] is current SFC architecture supporting different
> >>types of  SFC header formats?
> >>
> >> Hi, Georgios,
> >>
> >>not the  format.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 4 Dec 2014 15:18:28 +0000

Hi Georgios,

Please see inline.

> On Dec 4, 2014, at 9:40 AM, Georgios Karagiannis <[email-masked]> wrote:
> 
> Hi Carlos,
> 

Thanks for the clarification.

> SFC encapsulation technique and at the same time excluding other techniques.

Yes. Again, the SFC architecture document does not concern itself or take any position on any specifics for any encapsulation format. It does specify the functions that the SFC encapsulation need to fulfill.

> o) Explicit Route List, like format, see section 5.3 on boucadair draft, see below.

I see — this is a question for draft-boucadair-sfc-design-analysis and not for draft-ietf-sfc-architecture. Meaning, it would be up to the proposed encapsulation to show how they realize the functions of the architecture.

That said, I do not see an “SF Map Index” in the architecture document, for example.

Thanks,

Carlos.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 04 Dec 2014 10:32:05 -0500

To reinforce Carlos' point, the architecture document is quite careful 
not to specify how the required information is encoded in the header. 
It is up to the WG to select a single such encapsulation that meets the 
requirements from among the multiple choices being presented in 
individual drafts.

Yours,
Joel

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 4 Dec 2014 15:33:24 +0000

Hi Carlos,

Thank you very much for the clarification!

> I see — this is a question for draft-boucadair-sfc-design-analysis and not for
> draft-ietf-sfc-architecture. Meaning, it would be up to the proposed
> encapsulation to show how they realize the functions of the architecture.
> 

Georgios: Thanks, I see, so additional functions need to be added to the SFC architecture if one would like to support the Single Marking Code Point - like format.

What about the Explicit Route List. Section 5.6 of the SFC architecture draft mentions that "This architecture prescribes additional information being added to packets to identify service function paths and often to represent metadata. 
Can such an Explicit Route List being considered as metadata?

Best regards,
Georgios

> Sent: Thursday, December 04, 2014 4:18 PM
> To: Georgios Karagiannis
> Cc: [email-masked]
> > From what I understood from IETF'91 meeting discussions, the Generic SFC
> encapsulation technique has not yet been selected by the SFC WG.
> >
> > I think that this means that the SFC architecture draft cannot be in
> > favor for one specific SFC encapsulation technique and at the same time
> excluding other techniques.
> >
> 
> Yes. Again, the SFC architecture document does not concern itself or take any
> position on any specifics for any encapsulation format. It does specify the
> functions that the SFC encapsulation need to fulfill.
> 
> > My question is:
> >
> > Can the following two SFC encapsulation techniques be supported by the
> functions described in the SFC architecture draft?:
> >
> I see — this is a question for draft-boucadair-sfc-design-analysis and not for
> draft-ietf-sfc-architecture. Meaning, it would be up to the proposed
> encapsulation to show how they realize the functions of the architecture.
> 
> >> Looking at that section, the terminology does not seem to align to
> >> the arch and problem-statement documents. Also, that section seems to
> >> describe a pseudo-format, not a format. The architecture describes
> >> the functions in Section 4.1 and other places.
> >>
> >> Thanks,
> >>
> >> Carlos.
> >>

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 4 Dec 2014 15:47:31 +0000

Hi Joel,

Thanks for your email!
I understand that the SFC architecture draft does not specify how the required information is encoded in the header.

Therefore, I am also assuming that (1) the SFC Encapsulation function described in section 4.1, (2) the Classification function described in section 4.7 and (3) the Shared Metadata function described in Section 4.9, are described in such a way that any SFC encapsulation technique should be supported.

Best regards,
Georgios

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, December 04, 2014 4:32 PM
> To: Georgios Karagiannis
> Cc: [email-masked]
> To reinforce Carlos' point, the architecture document is quite careful not to
> specify how the required information is encoded in the header.
> requirements from among the multiple choices being presented in individual
> drafts.
> 
> Yours,
> Joel
> 
> > Yes. Again, the SFC architecture document does not concern itself or take
> any position on any specifics for any encapsulation format. It does specify
> the functions that the SFC encapsulation need to fulfill.
> >
> >> My question is:
> >>
> > I see — this is a question for draft-boucadair-sfc-design-analysis and not
> for draft-ietf-sfc-architecture. Meaning, it would be up to the proposed
> >>> the arch and problem-statement documents. Also, that section seems
> >>> to describe a pseudo-format, not a format. The architecture
> >>> describes the functions in Section 4.1 and other places.
> >>>
> >>> Thanks,
> >>>
> >>> Carlos.
> >>>
> >>>>> Subject: Re: [sfc] is current SFC architecture supporting
> >>>>> different types of  SFC header formats?
> >>>>>
> >>>>> Hi, Georgios,
> >>>>>
> >>>>>> architecture allows the use of different Service Function
> >>>>>> Chaining
> >>>>> Header
> >>>>> formats?
> >>>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 04 Dec 2014 10:56:35 -0500

Not quite "any".  The working group made some choices about behavior as 
part of the process.  If the architecture did not make any choices, then 
there would be no point in having the architecture.  We did not however 
mandate the specific encodings, and there are a fair range of possible 
realizations.  Neither I nor Carlos attempted to review all the existing 
proposals to determine if as they exist they fit the architecture or if 
they could be adjusted to fit.  That is up to the proposers.

For example, I suppose that one could write a solution proposal that 
required co-location of certain components.  But that would then be an 
important property of the proposal to be discussed by the WG.

Yours,
Joel

On 12/4/14, 10:47 AM, Georgios Karagiannis wrote:
> Hi Joel,
>
> Thanks for your email! I understand that the SFC architecture draft
> does not specify how the required information is encoded in the
> header.
>
> Therefore, I am also assuming that (1) the SFC Encapsulation function
> described in section 4.1, (2) the Classification function described
> in section 4.7 and (3) the Shared Metadata function described in
> Section 4.9, are described in such a way that any SFC encapsulation
> technique should be supported.
>
> Best regards, Georgios
>
>
>
>> -----Original Message----- From: Joel M. Halpern
>> [mailto:[email-masked]] Sent: Thursday, December 04, 2014 4:32
>> PM To: Georgios Karagiannis Cc: [email-masked] Subject: Re: [sfc] is
>> current SFC architecture supporting different types of SFC header
>> formats?
>>
>> To reinforce Carlos' point, the architecture document is quite
>> careful not to specify how the required information is encoded in
>> the header. It is up to the WG to select a single such
>> encapsulation that meets the requirements from among the multiple
>> choices being presented in individual drafts.
>>
>> Yours, Joel
>>
>>>> Please note that I do not mean to use different SFC
>>>> encapsulations
>> simultaneously.
>>>>
>>>
>>>> I think that this means that the SFC architecture draft cannot
>>>> be in favor for one specific SFC encapsulation technique and at
>>>> the same time
>> any position on any specifics for any encapsulation format. It does
>> specify the functions that the SFC encapsulation need to fulfill.
>>>
>>>> My question is:
>>>>
>>>> o) Single Marking Code Point, like format, see section 5.1 on
>>>> boucadair
>> draft, see below.
>>>>
>>>> o) Explicit Route List, like format, see section 5.3 on
>>>> boucadair draft,
>> see below.
>>>>
>>>
>>> I see — this is a question for
>>> draft-boucadair-sfc-design-analysis and not
>> for draft-ietf-sfc-architecture. Meaning, it would be up to the
>> proposed encapsulation to show how they realize the functions of
>> the architecture.
>>>
>>> That said, I do not see an “SF Map Index” in the architecture
>>> document, for
>> example.
>>>
>>> Thanks,
>>>
>>> Carlos.
>>>
Best regards,
>>>> Georgios
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message----- From: Carlos Pignataro (cpignata)
>>>>> [mailto:[email-masked]] Sent: Thursday, December 04, 2014
>>>>> 3:02 PM To: Georgios Karagiannis Cc: [email-masked] Subject:
>>>>> Re: [sfc] is current SFC architecture supporting different
>>>>> Do you mean different SFC Encapsulations simultaneously? The
>>>>> SFC charter says:
>>>>>
>>>>> <snip> 3. Generic SFC Encapsulation: This document will
>>>>> describe a single service-level data plane encapsulation
>>>>> format that:
>>>>>
>>>>> </snip>
>>>>>
>>>>> Looking at that section, the terminology does not seem to
>>>>> align to the arch and problem-statement documents. Also, that
>>>>> section seems to describe a pseudo-format, not a format. The
>>>>> architecture describes the functions in Section 4.1 and other
>>>>> places.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Carlos.
>>>>>
>>>>>> Does this mean that the SFC architecture is allowing the
>>>>>> use of different Service Function Chaining Header (SFC
>>>>>> encapsulation) formats?
>>>>>>
>>>>>> I am referring to the different SFC encapsulation formats
>>>>>> that are discussed in section 5 of the following ID:
Best regards,
>>>>>> Georgios
>>>>>>
>>>>>>
>>>>>>> -----Original Message----- From: Carlos Pignataro
>>>>>>> (cpignata) [mailto:[email-masked]] Sent: Thursday,
>>>>>>> December 04, 2014 2:46 PM To: Georgios Karagiannis Cc:
>>>>>>> [email-masked] Subject: Re: [sfc] is current SFC
>>>>>>> architecture supporting different types of  SFC header
>>>>>>> formats?
>>>>>>>
>>>>>>> Hi, Georgios,
>>>>>>>
>>>>>>> below, and I have a question:
>>>>>>>> architecture allows the use of different Service
>>>>>>>> Function Chaining
>>>>>>> Header formats?
>>>>>>>>
>>>>>>> following draft:
>>>>>>>>
>>>>>>>> Best regards, Georgios
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ sfc
>>>>>>>> mailing list [email-masked]
>>> _______________________________________________ sfc mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 4 Dec 2014 16:10:07 +0000

Georgios,

> On Dec 4, 2014, at 10:33 AM, Georgios Karagiannis <[email-masked]> wrote:
> 
> Hi Carlos,
> 

No — it’s actually the other way around. The architecture does not retrofit a format proposal.

As Joel said, it’s not just “any” SFC encap proposal. The architecture made choices, and encap proposals realize the architecture with different encodings.

> Can such an Explicit Route List being considered as metadata?

The architecture describes what is necessary in the SFC encapsulation, what is metadata, and what the SFC encapsulation is not. 

Thanks,

Carlos.

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 4 Dec 2014 16:17:27 +0000

Hi Carlos, Hi Joel,

Thanks for the clarifications! 

This means that some selection steps for choosing the candidate SFC encapsulation 
have been already taken.

Best regards,
Georgios

> Sent: Thursday, December 04, 2014 5:10 PM
> To: Georgios Karagiannis
> Cc: [email-masked]
> >> I see — this is a question for draft-boucadair-sfc-design-analysis
> >> and not for draft-ietf-sfc-architecture. Meaning, it would be up to
> >> the proposed encapsulation to show how they realize the functions of the
> architecture.
> >>
> >> document, for example.
> > Georgios: Thanks, I see, so additional functions need to be added to the SFC
> architecture if one would like to support the Single Marking Code Point - like
> format.
> >
> 
> As Joel said, it’s not just “any” SFC encap proposal. The architecture made
> choices, and encap proposals realize the architecture with different encodings.
> 
> > What about the Explicit Route List. Section 5.6 of the SFC architecture
> draft mentions that "This architecture prescribes additional information being
> added to packets to identify service function paths and often to represent
> metadata.
> The architecture describes what is necessary in the SFC encapsulation, what is
> metadata, and what the SFC encapsulation is not.
> 
> Thanks,
> 
> Carlos.
> 
> > Best regards,
> > Georgios
> >
> >
> >
> >
> >
> >> Yes. Again, the SFC architecture document does not concern itself or
> >> take any position on any specifics for any encapsulation format. It
> >> does specify the functions that the SFC encapsulation need to fulfill.
> >>
> >>> My question is:
> >>>
> >>> o) Explicit Route List, like format, see section 5.3 on boucadair
> >>> draft, see
> >> below.
> >>>
> >>
> >> I see — this is a question for draft-boucadair-sfc-design-analysis
> >> and not for draft-ietf-sfc-architecture. Meaning, it would be up to
> >> the proposed encapsulation to show how they realize the functions of the
> architecture.
> >>
> >> document, for example.