Subject: [sfc] Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT)

From: "Alvaro Retana" <[email-masked]>
Date: Wed, 27 May 2015 19:05:23 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-sfc-architecture-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I want to talk about the intended status of this document: right now
(-08) it is marked as Informational, but up to -06 it was intended to be
on the Standards Track.  Why did this change?  [I looked at the archives,
but couldn’t find a specific reason or discussion.]

>From the Abstract: 

   This document describes an architecture for the specification,
   creation, and ongoing maintenance of Service Function Chains (SFC) in
   a network.  It includes architectural concepts, principles, and
   components used in the construction of composite services through
   deployment of SFCs, with a focus on those to be standardized in the
   IETF. 

If this architecture is what ongoing standardization of SFC should be
based on, then I think it should be on the Standards Track.  There are
already a number of drafts that intend to be on the standards track that
are using this document as a normative reference [1], which makes sense
based on the text above.  Note that none of the drafts that use the
document as a normative reference have been adopted by the WG, but the
point is still the same: if the intent is for this document to be used as
a base for future standardization, then I think it should belong in the
standards track.  I know that we can always add a downref exception, but
why would that be necessary if this document is intended to be guide
future standardization for SFC?

OTOH, if the WG decided that this is just “an architecture” (vs. *the*
architecture), and that is why the intended status changed in -07, then
it should be made clear in the text.

[1]
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/referencedby/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just a couple of other comments:

1. Section 1.1(Scope): “This document defines the architecture for
Service Function Chaining (SFC) with minimum requirements on the physical
topology of the network, as standardized in the IETF.”  What is
standardized, the physical topology?  Confusing sentence.

2. Section 5.2 (SFC Control Plane): “This is part of the overall
architecture but outside the scope of this document.”   I don’t
understand how the control plane, being part of the architecture, is not
in scope of the architecture document..??   Especially since in this
section there is a discussion of the functionality to be provided by the
control plane.  What am I missing?

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 May 2015 02:44:12 +0000

Hi, Alvaro,

Thanks for your review! Please see inline.

> On May 27, 2015, at 10:05 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 

Initially we (editors) thought STD was appropriate for the exact same reasons you list below.

For context, the question of the intended status arose when the chairs were preparing the write up.

An analysis of other architectures showed no definitive pattern, although other working groups seemed to now be using Informational for their architecture documents (e.g., I2RS, although 6tisch is targeting STD)

Thomas summarized the criteria as follows:
“One key test is "how would you advance the document up the standards track and what would the interoperability tests be?” Some (not many) architecture documents do have protocol-like stuff in them. I can't say this one does.”

And we changed it to Info before submitting to the IESG.

Frankly, we take your guidance on this. Neither chairs, editors, or the WG seemed hang up on either intended status — please discuss it and let us know.

> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/referencedby/

Will fix — thanks.

> control plane.  What am I missing?

The WG agreement was that a detailed analysis of the control plane mechanisms to set up SFCs was outside the scope. While we list high-level CP functions, this document does not prescribe CP details.

This said, I agree that the way that particular sentence reads seems self-contradicting.

Perhaps, something like this?

   The SFC Control Plane is part of the overall SFC architecture,
   and this section describes its high-level functions. However, the
   detailed definition of the SFC Control Plane is outside the scope
   of this document.

Thanks,

— Carlos.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 28 May 2015 02:54:58 +0000

On 5/27/15, 10:44 PM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

Carlos:

Hi!

>>2. Section 5.2 (SFC Control Plane): ³This is part of the overall
>>architecture but outside the scope of this document.²   I don¹t
>The WG agreement was that a detailed analysis of the control plane
>mechanisms to set up SFCs was outside the scope. While we list high-level
>CP functions, this document does not prescribe CP details.
>

That works for me.

Thanks!

Alvaro.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 May 2015 02:56:08 +0000

Thanks ― changes made in our working copy.

― Carlos.

-----Original Message-----
From: Alvaro Retana <[email-masked]>
Date: Wednesday, May 27, 2015 at 10:54 PM
To: Carlos Pignataro <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>,
Jim Guichard <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: Alvaro Retana's Discuss on draft-ietf-sfc-architecture-08:
(with DISCUSS and COMMENT)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 00:13:54 -0400

It is fine with me too.
Yours,
Joel

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 May 2015 09:28:23 -0400

> based on, then I think it should be on the Standards Track.

I was thinking the same thing when I started to look at this document
(I haven't finished, and won't have time to finish before the
telechat).  I agree with Àlvaro in the general case: unlike, say, use
cases, architecture on which Standards-Track protocols will be based
should itself be Standards Track.

Barry

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 May 2015 09:37:30 -0400

I don't see anything specifically implementable in this architecture.  I
can't see how it could proceed
from PS to IS.  That isn't the case for all architecture docs, but for this
one, I think that Informational
is fine.  I'm happy to discuss why you think otherwise.

Alia

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 May 2015 09:56:34 -0400

> one, I think that Informational is fine.

I could see how the proposed architecture could be refined and
eventually moved past "proposed", but that's not the main point I'm
thinking about.  For me, it's a question of the type of review
Standards Track documents get ("Is this document a reasonable basis on
which to build the salient part of the Internet infrastructure? If
not, what changes would make it so?") as compared with Informational
("Is this document a reasonable contribution to the area of Internet
engineering which it covers? If not, what changes would make it so?").

We are proposing the former: building a significant part of the
Internet infrastructure on this.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 May 2015 09:58:25 -0400

> Internet infrastructure on this.

That said, I'll add that the IESG review does seem to be in line with
the former already.

Barry

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 May 2015 10:05:51 -0400

Barry,

> engineering which it covers? If not, what changes would make it so?").

I don't feel that this draft has suffered in any way from a lack of review.
I think that we do review architectures with a good expectation that they
are
a solid basis.

I think that the status should depend on what the draft is - not on the
level of
review that we think is appropriate.

> Internet infrastructure on this.

Well, not precisely.  I do expect it to be significantly deployed but I
also see it
as being within individual administrative domains.

Alia

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 May 2015 10:14:57 -0400

> are a solid basis.

As I said in my follow-up note, I do agree with what you say there.

> level of review that we think is appropriate.

That's something we can discuss in another thread/context; I don't
think I agree, but discussion would be lovely.

> Well, not precisely.  I do expect it to be significantly deployed but I also
> see it as being within individual administrative domains.

Ack.

Given that I think the review of this document has been good, I'm not
a holdout here either way.  I just wanted to make my point, and I
have.  T'anks.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 14:59:37 +0100

> Internet infrastructure on this.

I don't care about the RFC status.

But one of my comments was to the effect that I think this
would be much more useful if the WG took it back and put
it on ice until they'd developed the protocol and then go
back and tweak this. I think the result would be much more
useful then. (And would be obviously a thing for the
standards track, I bet.)

S.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 May 2015 10:07:42 -0400

Stephen,

> useful then. (And would be obviously a thing for the

I did see that suggestion.  The WG has been focusing on the architecture and
encapsulation.  There are many different ways of doing the protocol and the
WG is just barely starting to consider discussing them.  I do agree that the
architecture is a carefully crafted compromise.

Alia

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 29 May 2015 17:50:02 +0000

Alvaro, Alia,

Happy Friday!

> On May 27, 2015, at 10:05 PM, Alvaro Retana (aretana) <[email-masked]> wrote:

Are there any conclusions from the teletext that would guide the intended status of this architecture?

Please let us know — thanks!

— Carlos.