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

[<[e-mail]>]

Hi Greg, Dave,

Please see inline.

Cheers,
Med

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

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

See inline [DD].

-Dave


From: Greg Mirsky [mailto:[e-mail]]
Sent: Tuesday, July 4, 2017 6:06 PM
To: Dave Dolson
Cc: [e-mail]<mailto:[e-mail]>
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





   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.



[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.

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

·         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?

[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.

·         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.

[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).

·         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”?

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

·         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.

[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.

·         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 <[e-mail]<mailto:[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]<mailto:[e-mail]>] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, June 30, 2017 3:47 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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