Subject: [sfc] draft-ietf-sfc-architecture

From: "ietfdbh" <[email-masked]>
Date: Mon, 8 Sep 2014 19:12:45 -0400

Hi,

I read draft-ietf-sfc-architecture and have a couple comments.

In section 1.3, you use a number of abbreviations, such as SFP and SFC,
which have not yet been defined or discussed.
These should be spelled out on first use in the document.
Or you could reorder the terminology section so it is not forward
referencing.
(If the order was alphabetical, there would be a case for forward
references, but it's not alphabetical either.)

I know this is being developed in the routing area, but FIB and RIB are not
defined in this document, and there is no reference for the terms.
I'm sure you could argue that anybody that doesn't know what a FIB or RIB is
shouldn't be reading this document.
But it could also be argued that since FIB and RIB are mentioned no place in
this document except in these assumptions, that the assumption isn't needed.
I think the simplest solution is to point to references for FIB and RIB.

The SFC Encapsulation definition is especially difficult, because it talks
about things that are not defined in this document, such as "dataplane
context".
It also references "metadata" but "metadata" is not included in the
terminology section.

The definition of service functions says "One of multiple Service Functions
can be embedded in the same network element." Is that supposed to be an
"or"?

"Multiple occurrences of the Service Function can exist in the same
administrative domain."
Can multiple occurrences of the service function exist in the same network
device?
I'm working with applications that can be configured to provide services
differently, and multiple instances run on the same host.

"constraints that must be applied" seems incorrect, since the rest of the
paragraph talks about exceptions to the must. 
How about s/that must/to/ ?

In 2.2, there is a discussion of state tradeoffs. A parenthesized example is
(S->D and D->S); I haven't got a clue what the S and D mean.

In section 3, point 2, I don't know what "dynamic realization of SFPs"
means.

Section 4.2 has a paragraph discussing SF Proxy. I think this would be
better under 4.6. 
What a proxy is does not seem important when describing an SF.

In 4.3, "Traffic from SFs
   eventually returns to the same SFF, which is responsible for putting
   it back onto the network." I don't understand this sentence. 
First, I recommend replacing "it" with something more concrete. I'm not sure
what the SFF "puts back" on the network.
Second, I'm not sure that this agrees with section 1.3, which says an SFF
delivers from the network to a SF.

Editorial nit: "It should be noted that ..."; well, it's a good thing you
noted then, isn't it? Now that you've noted it, you can remove this
preamble.

"an SFF should be able to interact with metadata" - interact feels wrong
here. Does an SFF only need to be able to interpret metadata? To modify
metadata? What other types of interaction are expected?

5.5 talks about SPFs; is this supposed to be SFP?

Administrateive

David Harrington
[email-masked]
+1-603-828-1401

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Sep 2014 18:58:56 -0400

The reference for FIB that the RFC editor lists is RFC 1322.  I doubt 
that a reference to RFC 1322 in the document would help folks much.  And 
they list RIB as a common abbreviation but without a reference, 
suggesting that there is no good agreed reference for it.
https://www.rfc-editor.org/rfc-style-guid/abbrev-expansion.txt.

> I read draft-ietf-sfc-architecture and have a couple comments.
...
> I think the simplest solution is to point to references for FIB and RIB.
...

---

From: Barry Greene <[email-masked]>
Date: Fri, 12 Sep 2014 06:49:31 +0700

There are some good referenced in the BMWG RFCs on FIB and RIB. Check them out. 

On Sep 12, 2014, at 5:58 AM, Joel M. Halpern <[email-masked]> wrote:

> The reference for FIB that the RFC editor lists is RFC 1322.  I doubt that a reference to RFC 1322 in the document would help folks much.  And they list RIB as a common abbreviation but without a reference, suggesting that there is no good agreed reference for it.
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Sep 2014 20:08:40 -0400

Thanks Barry.  I'll take a look.  Can you point me at a starting point 
to follow?

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 12 Sep 2014 13:56:25 +0000

For FIB on BMWG's work, the most precise definition is probably in Section 5.3 of RFC3222 <http://tools.ietf.org/html/rfc3222#section-5.3>, but that in turn points to Appendix B of RFC1812. 

For RIB on BMWG's RFCs, I only remember and could only find RFC 4098, which does not really include a "Definition" per se.

Net-net, these citations would not add much, I think.

We are probably better off generalizing the concept, like:
"
   o  No assumption is made on how the information necessary to forward packets and the information necessary to route packets is populated on the involved devices.
"
Would this be better? Or just assume RIB and FIB are very well known?

Thanks,

Carlos.

On Sep 11, 2014, at 8:08 PM, Joel M. Halpern <[email-masked]> wrote:

> Thanks Barry.  I'll take a look.  Can you point me at a starting point to follow?
> 
> Yours,
> Joel
>

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 11 Sep 2014 19:51:53 -0400

Oh well ...

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, September 11, 2014 6:59 PM
> To: ietfdbh; [email-masked]
> Cc: [email-masked]
> Subject: Re: [sfc] draft-ietf-sfc-architecture
> 
> > I'm sure you could argue that anybody that doesn't know what a FIB or
RIB
> is

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 12 Sep 2014 15:32:49 +0000

Hi, David,

Please see inline.

> references, but it's not alphabetical either.)

As you noted, all all the terms are defined within the section, and the section is self-contained. I will reorder the terms so that acronyms used are always previously defined.

> I think the simplest solution is to point to references for FIB and RIB.

Discussed in the forked thread.

> It also references "metadata" but "metadata" is not included in the

Metadata is implicitly defined as "the SFC encapsulation carries dataplane context
        information, also referred to as metadata."

It is further explained below in the document (S3 and S4.9).

But yes, I can add a short definition.

> can be embedded in the same network element." Is that supposed to be an

Yes, thanks!

> differently, and multiple instances run on the same host.

There's nothing in the text preventing this.

> How about s/that must/to/ ?

I don't see how "constraints that must be applied" is incorrect, or how "to" would make it correct -- the sentence seems to flow fine considering the text that follows.

> (S->D and D->S); I haven't got a clue what the S and D mean.

In the context of SFC Symmetry (which is the section in which you find the example), S == Source; D == Destination, consistent with Fig 4 and Fig 5. 

That said, however, it does not matter much in reality what the letters mean.

I will clarify this by replacing with "from Source to Destination and from ...".

> In section 3, point 2, I don't know what "dynamic realization of SFPs"

Realizing the SFP dynamically :-)

> What a proxy is does not seem important when describing an SF.

It's important for the SF to define SFC-awareness, and its relation to the SFC encapsulation. I think the paragraph fits there fine, but to your point, I will add a forward pointer to S 4.6.

> delivers from the network to a SF.

I will s/putting it/injecting traffic/. (if you prefer, I can use "handling traffic" as well)

Overall, this seems consistent with Section 1.3:

   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation, as well as handling traffic
        coming back from the SF.

> noted then, isn't it? Now that you've noted it, you can remove this

Noted.

> 5.5 talks about SPFs; is this supposed to be SFP?

Ack -- thanks for the review!

Carlos.