Subject: Re: [sfc] I-D Action: draft-ietf-sfc-hierarchical-03.txt

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Jul 2017 15:06:26 -0700

Hi Dave, Authors,
thank you for very interesting approach to the problem of SFC complexity.
Great well-written document. Please kindly consider my comments, questions:

   - even though the draft is targeted for Informational track, I'd
   encourage include wording from RFC 8174 that clarifies use of normative
   words:

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
BCP <https://tools.ietf.org/html/bcp14>
   14 <https://tools.ietf.org/html/bcp14> [RFC2119
<https://tools.ietf.org/html/rfc2119>] [RFC8174
<https://tools.ietf.org/html/rfc8174>] when, and only when, they
appear in all
   capitals, as shown here.

   - I think that adding section with acronyms listed will be helpful
to the reader.
   - Is "stickiness to specific SF instances" another way to say that
SF is stateful? And the same question for types of SFs that require
bidirectional traffic (I think that such requirement implies what
later referred as stickiness, i.e. reverse direction must cross the
same SF instance as the forward direction of SFC).
   - I'm not sure that assumption in Section 2.2 regarding
encapsulation of the packets entering lower-level SFC domain. What you
see as the transport between SFF of the higher-level and IBN?
   - section 3.1.1 refers to IBN as"terminator of lower-level chain".
As I understand, IBN is the representation, proxy of the lower-level
chain in the higher-level. Right? If my understanding is correct, some
terminology alignment may be helpful.
   - Figure 3. What is seen as overlay encapsulation? I'd probably
refer to the outer header as Transport or Underlay without going into
gory details of what it is. But more importantly, in my view, is to
clarify where, at which point in hSFC, hSFC packet has format
presented in Fig.3. I'd imagine that lower-NSH is to be added by the
Classifier of the sub-domain. But would SFF that being handed the
resulting packet have the Transport Header to deal with?
   - I think that sections 3.3 and 3.4 are related as there's some
duplication between SI and TTL that was pointed on the NSH thread by
Igor. Thus policies that regulate handling of SI and TTL may need to
be synchronized or coordinated to have predictable behavior.
   - I think that section 3.4 may benefit from using RFC 3443
terminology in regard to TTL handling between inner and outer headers
and refer to Unified, Short Pipe, and Pipe.
   - does the first paragraph in section 4 refer to IBN removing
higher-level NSH? I thought that is one possible solution and other
solutions may rely on information in the higher-level NSH being
available to the sub-domain Classifier.
   - there's another term very close to bidirectional symmetry as
defined in section 4 - co-routed path. Co-routed path is bidirectional
path that traverses the same set of links and nodes in forward and
reverse directions and is viewed as single entity, e.g. failure in one
direction viewed as bi-directional failure. May be co-routed path be
used as reference or as term in (h)SFC .

Regards,

Greg

On Fri, Jun 30, 2017 at 1:02 PM, Dave Dolson <[email-masked]> wrote:

> SFC WG,
>
> This new version hopefully addresses some of the comments received on the
> list.
> It also uses the new NSH header format, with some language about handling
> the TTL in the sub-domains.
> (I've written that whether to expose the hops of the sub-domain is
> administrator choice.)
>
> Hopefully my changes are acceptable to the working group.
> I'm more than happy to discuss this with anyone.
>
> I think the main outstanding issue is whether we should reduce the number
> of options in sections 3.1.1 thru 3.1.5 be reduced?
> On one hand, the start and end of sub-domain chains are within the purview
> of a single vendor.
> On the other hand, 5 options is too many.
>
> See you in Prague,
> -Dave
>
>
> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, June 30, 2017 3:47 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-03.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Service Function Chaining of the IETF.
>
>         Title           : Hierarchical Service Function Chaining (hSFC)
>         Authors         : David Dolson
>                           Shunsuke Homma
>                           Diego R. Lopez
>                           Mohamed Boucadair
>                           Dapeng Liu
>                           Ting Ao
>                           Vu Anh Vu
>         Filename        : draft-ietf-sfc-hierarchical-03.txt
>         Pages           : 26
>         Date            : 2017-06-30
>
> Abstract:
>    Hierarchical Service Function Chaining (hSFC) is a network
>    architecture allowing an organization to decompose a large-scale
>    network into multiple domains of administration.
>
>    The goals of hSFC are to make a large-scale network easier to reason
>    about, simpler to control and to support independent functional
>    groups within large network operators.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-03
> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-hierarchical-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-hierarchical-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 5 Jul 2017 19:47:32 +0000

Greg,
Thank you for giving your time to reading and providing comments.

See inline [DD].

-Dave

From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, July 4, 2017 6:06 PM
To: Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-hierarchical-03.txt

Hi Dave, Authors,
thank you for very interesting approach to the problem of SFC complexity. Great well-written document. Please kindly consider my comments, questions:

  *   even though the draft is targeted for Informational track, I'd encourage include wording from RFC 8174 that clarifies use of normative words:

Requirements Language

   "OPTIONAL" in this document are to be interpreted as described in BCP<https://tools.ietf.org/html/bcp14>

   14<https://tools.ietf.org/html/bcp14> [RFC2119<https://tools.ietf.org/html/rfc2119>] [RFC8174<https://tools.ietf.org/html/rfc8174>] when, and only when, they appear in all

   capitals, as shown here.

[DD] Good point; we have not used any upper-case requirements keywords. I think we would have to very carefully review where those are appropriate.

·         I think that adding section with acronyms listed will be helpful to the reader.

[DD] we have tried to define acronyms as they are introduced, but we could easily add that.

·         Is "stickiness to specific SF instances" another way to say that SF is stateful? And the same question for types of SFs that require bidirectional traffic (I think that such requirement implies what later referred as stickiness, i.e. reverse direction must cross the same SF instance as the forward direction of SFC).

[DD] Yes. (NATs and firewalls are listed as examples.)  I think I can address your concern with addition of “stateful” adjective.

·         I'm not sure that assumption in Section 2.2 regarding encapsulation of the packets entering lower-level SFC domain. What you see as the transport between SFF of the higher-level and IBN?

[DD] We intend that the IBN acts as an SF of the higher-level domain. Hence it receives packets as any SF would. Is there some place I can make this more clear?

·         section 3.1.1 refers to IBN as"terminator of lower-level chain". As I understand, IBN is the representation, proxy of the lower-level chain in the higher-level. Right? If my understanding is correct, some terminology alignment may be helpful.

[DD] terminating the lower-level chain is one role of the IBN. In other SFC deployments, a chain terminator may be at a router or a switch; after the chain ends, the packet is removed from NSH and routed or switched according to the IP or link-layer header respectively. However, in the IBN the lower-level termination results in restoration to the upper-level path. Does that help explain it?

[DD] I’m unclear on which terminologies need to be aligned with each other.

·         Figure 3. What is seen as overlay encapsulation? I'd probably refer to the outer header as Transport or Underlay without going into gory details of what it is. But more importantly, in my view, is to clarify where, at which point in hSFC, hSFC packet has format presented in Fig.3. I'd imagine that lower-NSH is to be added by the Classifier of the sub-domain. But would SFF that being handed the resulting packet have the Transport Header to deal with?

[DD] In figure 3, “Overlay Header” means how the NSH is carried. Would this be better aligned with draft-ietf-sfc-nsh by referring to it as “NSH Encapsulation”?

·         I think that sections 3.3 and 3.4 are related as there's some duplication between SI and TTL that was pointed on the NSH thread by Igor. Thus policies that regulate handling of SI and TTL may need to be synchronized or coordinated to have predictable behavior.

[DD] I don’t understand why coordination would be required. SI is decremented by SFs, whereas TTL is decremented by SFFs. But I think clarity could be improved here with use of normative words per your first point.

·         I think that section 3.4 may benefit from using RFC 3443 terminology in regard to TTL handling between inner and outer headers and refer to Unified, Short Pipe, and Pipe.

[DD] Thanks for the pointers to Uniform, Pipe and Short Pipe. We will see about using these.

·         does the first paragraph in section 4 refer to IBN removing higher-level NSH? I thought that is one possible solution and other solutions may rely on information in the higher-level NSH being available to the sub-domain Classifier.

[DD] Agreed, this language is incorrect for some of the solutions. We will fix it.

·         there's another term very close to bidirectional symmetry as defined in section 4 - co-routed path. Co-routed path is bidirectional path that traverses the same set of links and nodes in forward and reverse directions and is viewed as single entity, e.g. failure in one direction viewed as bi-directional failure. May be co-routed path be used as reference or as term in (h)SFC .

[DD] Would it suffice to explain, “In other words, a sub-domain classifier can ensure co-routed paths for bidirectional traffic.” ?

Regards,

Greg

On Fri, Jun 30, 2017 at 1:02 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
SFC WG,

This new version hopefully addresses some of the comments received on the list.
It also uses the new NSH header format, with some language about handling the TTL in the sub-domains.
(I've written that whether to expose the hops of the sub-domain is administrator choice.)

I think the main outstanding issue is whether we should reduce the number of options in sections 3.1.1 thru 3.1.5 be reduced?
On one hand, the start and end of sub-domain chains are within the purview of a single vendor.
On the other hand, 5 options is too many.

See you in Prague,
-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, June 30, 2017 3:47 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Service Function Chaining of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

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

---

From: <[email-masked]>
Date: Thu, 6 Jul 2017 06:46:35 +0000

Hi Greg, Dave,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : mercredi 5 juillet 2017 21:48
À : Greg Mirsky
Cc : [email-masked]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-hierarchical-03.txt

Greg,

See inline [DD].

-Dave

Hi Dave, Authors,

Requirements Language

   capitals, as shown here.

[Med] I would not use the normative language given that we are discussing options and not making a recommendation.

[Med] We can make it clear by making this change in Section 2.2:

OLD:
   Unlike the top level, data packets entering the sub-domain are
   already SFC-encapsulated.  Figure 2 shows a sub-domain interfaced
   with a higher-level domain by means of an Internal Boundary Node
   (IBN).  It is the purpose of the IBN to apply classification rules
   and direct the packets to the selected local SFPs terminating at an
   egress IBN.  The egress IBN finally restores packets to the original
   SFC shim and hands them off to SFFs.

NEW:
   Figure 2 shows a sub-domain interfaced with a higher-level
   domain by means of an Internal Boundary Node (IBN).
   An IBN acts as an SFC-aware SF in the higher-level
   domain and as a classifier in the lower-level domain. As such,
   data packets entering the sub-domain are already SFC-encapsulated.
   Also, it is the purpose of the IBN to apply classification rules
   and direct the packets to the selected local SFPs terminating at an
   egress IBN. The egress IBN finally restores packets to the original
  SFC shim and hands them off to SFFs.

[Med] We can avoid the use of “terminator” and calls explicitly the “SFP terminating” feature of an IBN. A proposed change to Section 3.1.1 is provided below:

OLD:
   When a packet returns to the IBN at the end of a chain (which is the
   terminator of the lower-level chain)

NEW:
   When a packet returns to the IBN at the end of a chain (which is the
   SFP terminating node of the lower-level chain).

[Med] This is the “outer-transport encapsulation” as per RFC7665.

[Med] Agree with Dave. Further, if any coordination is required, it wouldn’t be specific to hSFC but be valid for SFC in general. I don’t think we need to discuss this “issue” in this document.

Regards,

Greg

See you in Prague,
-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, June 30, 2017 3:47 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-03.txt

Abstract: