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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Friday, June 30, 2017 3:47 PM
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>