Hierarchical Service Function Chaining (hSFC)
draft-ietf-sfc-hierarchical-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-09-15
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-09-06
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-08-08
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-06-26
|
11 | (System) | IANA Action state changed to No IC from In Progress |
2018-06-26
|
11 | (System) | RFC Editor state changed to EDIT |
2018-06-26
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-06-26
|
11 | (System) | Announcement was received by RFC Editor |
2018-06-26
|
11 | (System) | IANA Action state changed to In Progress |
2018-06-26
|
11 | Martin Vigoureux | Intended Status changed to Experimental from Informational |
2018-06-26
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-06-26
|
11 | Amy Vezza | IESG has approved the document |
2018-06-26
|
11 | Amy Vezza | Closed "Approve" ballot |
2018-06-26
|
11 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-06-26
|
11 | Martin Vigoureux | Ballot approval text was generated |
2018-06-25
|
11 | Mohamed Boucadair | New version available: draft-ietf-sfc-hierarchical-11.txt |
2018-06-25
|
11 | (System) | New version approved |
2018-06-25
|
11 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Mohamed Boucadair , Shunsuke Homma , Diego Lopez |
2018-06-25
|
11 | Mohamed Boucadair | Uploaded new revision |
2018-06-22
|
10 | Benjamin Kaduk | [Ballot comment] Thanks for the quick updates to the document. As previously indicated, I am Abstaining, since this document includes a proposal for adding a … [Ballot comment] Thanks for the quick updates to the document. As previously indicated, I am Abstaining, since this document includes a proposal for adding a new category of NSH metadata contents, and as discussed during RFC 8300's evaluation there is not a mandatory integrity protection option for such metadata. |
2018-06-22
|
10 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to Abstain from Discuss |
2018-06-22
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-06-22
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-06-22
|
10 | Mohamed Boucadair | New version available: draft-ietf-sfc-hierarchical-10.txt |
2018-06-22
|
10 | (System) | New version approved |
2018-06-22
|
10 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Mohamed Boucadair , Shunsuke Homma , Diego Lopez |
2018-06-22
|
10 | Mohamed Boucadair | Uploaded new revision |
2018-06-21
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-06-21
|
09 | Cindy Morgan | Changed consensus to Yes from Unknown |
2018-06-21
|
09 | Alissa Cooper | [Ballot comment] I agree with Benjamin's DISCUSS. In particular, each of the options presented in Section 4.1 seem to have challenges that could render them … [Ballot comment] I agree with Benjamin's DISCUSS. In particular, each of the options presented in Section 4.1 seem to have challenges that could render them unworkable, and no insights from deployment experience are provided to explain why they are in fact workable in practice. I think it would be preferable to do the further analysis suggested by Alvaro before publishing an informational document about hSFC. With that said, given that this is an informational document I wouldn't stand in the way of it being published. |
2018-06-21
|
09 | Alissa Cooper | [Ballot Position Update] New position, Abstain, has been recorded for Alissa Cooper |
2018-06-21
|
09 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-06-20
|
09 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-06-20
|
09 | Suresh Krishnan | [Ballot comment] I am balloting No Objection but I share Alvaro's concern that the document needs to do further work on analyzing (and potentially narrowing … [Ballot comment] I am balloting No Objection but I share Alvaro's concern that the document needs to do further work on analyzing (and potentially narrowing down) the options in order to be useful. |
2018-06-20
|
09 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-06-20
|
09 | Benjamin Kaduk | [Ballot discuss] This does seem like an interesting and potentially useful idea -- thanks for doing the work! However, I am not sure that the … [Ballot discuss] This does seem like an interesting and potentially useful idea -- thanks for doing the work! However, I am not sure that the document as-is is suitable for publication. In Section 4.1.5 we hear that preserving metadata and applying metadata to injected packets is not special and is "usual" functionality, but section 4.1.2 calls out that the 4.1.2 approach requires the SFs in the path to be capable of forwarding metadata and attaching metadata to injected packets as if it is a nontrivial requirement. This apparent internal inconsistency needs to be resolved before publication. Why does Section 4.1 offer five different choices with no guidance on how to make a cost/benefit analysis amongst them? Is the full spread of five choices really necessary? Complexity breeds implementation bugs which breed security issues, so I feel that this breadth of choice needs to be justified. This also ties into some confusion I have as to the goal of this document (which currently targets Informational status), akin to what is stated in Alvaro's ballot position: is it just providing information on how to assemble existing pieces in a novel way, or presenting a new protocol specification that is not yet fit for Proposed Standard status, or is it listing out potential solutions to a problem so that they can be implemented and experience gained as to which are useful in practice and which are not? Accordingly, I would be interested to hear about what deployment experience exists already and whether this abstraction proves to be as useful as the use cases seem to promise; if there is little implementation experience, perhaps Experimental status is more appropriate. I further am uncertain as to whether the approach described in Section 4.1.3 even merits consideration at all; the technique it describes seems to have a very leaky abstraction barrier (e.g., w.r.t TTL modifications). This seems especially poignant given the already large size of candidate approaches. The approach described in Section 4.1.5 also seems to be incompletely specified, in that the hSFC Flow ID semantics are not covered at all. On my initial reading I assumed that this field's encoding and semantics were intended to be left as entirely local matters to the lower domain, avoiding a need to specify them in this document. However, I'm not sure that it's actually true, since we generally want multiple vendors to be able to interoperate, and this scheme does not appear to require that the node applying the hSFC Flow ID (and saving state) is the same node that removes it (and restores state). That is, these two nodes could potentially be implemented by different vendors. Even once the above issues are resolved, I will only be able to move to an Abstain position, since this document proposes additional usage of (meta)data in the NSH headers that is not subject to mandatory integrity protection, as was discussed at length for RFC 8300 and is mandated to be available by RFC 7665. |
2018-06-20
|
09 | Benjamin Kaduk | [Ballot comment] Section 4 To achieve the benefits of hierarchy, the IBN should be applying more granular traffic classification rules at the lower … [Ballot comment] Section 4 To achieve the benefits of hierarchy, the IBN should be applying more granular traffic classification rules at the lower level than the traffic passed to it. This means that the number of SFPs within the lower level is greater than the number of SFPs arriving to the IBN. "more granular" and "less granular" are unfortunately ambiguous in practical usage; I suggest "fine-grained" as an alternative for this usage. Section 4.1.5 Figure 4's caption should indicate where the base NSH fixed-length context header is originally defined. Section 4.4 presents another operational choice that contributes to exponential complexity growth, and further highlights unique properties of the Section 4.1.3 approach that may render it unsuitable for inclusion. Section 7.2 Other fundamental functions required as IBN (e.g., maintaining metadata of upper level or decrementing Service Index) are same as normal usage. nit: "the same as in normal usage" Also, I think the two occurrences of "to permit specific metadata types" should be "to *only* permit specific metadata types". Section 10.1 Security considerations related to the control plane should be discussed in the corresponding control specification documents (e.g., [I-D.ietf-bess-nsh-bgp-control-plane], [I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius]). I'm going to call this a nit, but "should be discussed" sounds as if this document is trying to direct the behavior of the other listed documents; maybe "are discussed" is better. Section A.1 could perhaps note the potential drawback that the classification functionality is now distributed across the domains instead of being totally centralized at the initial entry, which requires greater coordination between the different classifers. (This is, of course, not necessarily a drawback for all deployments, but could be for some.) |
2018-06-20
|
09 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-06-20
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-06-19
|
09 | Ben Campbell | [Ballot comment] §10: "This document describes systems that may be managed by distinct teams of a single administrative entity." I had to re-read this a … [Ballot comment] §10: "This document describes systems that may be managed by distinct teams of a single administrative entity." I had to re-read this a few times to realize you meant distinct teams that are all part of the same entity, not distinct teams each made up of one entity. |
2018-06-19
|
09 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-06-19
|
09 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-06-19
|
09 | Alvaro Retana | [Ballot comment] The hSFC concept is indeed interesting -- thanks for doing the work! Reading through the document, I found myself thinking about its usefulness. … [Ballot comment] The hSFC concept is indeed interesting -- thanks for doing the work! Reading through the document, I found myself thinking about its usefulness. The Introduction says that it "focuses on the difficult problem of implementing SFC across a large, geographically dispersed network, potentially comprised of millions of hosts and thousands of network forwarding elements, and which may involve multiple operational teams (with varying functional responsibilities)." However, the content doesn't deal directly with the implementation/operational issues -- and offers instead a list of options around the IBN, with no clear or explicit recommendation. Even though it is not explicitly mentioned anywhere, I think that is the intent of the document. The options themselves include speculation about how things could work; including, for example, state synchronization between IBNs (§4.1.1) without specific proposals...or, my favorite, the nesting of NSH headers (§4.1.4). I note that even though the NSH spec (rfc8300) offers a Next Protocol value of "NSH", and the architecture (rfc7665) is such that "the SFC encapsulation remain transport independent...[and]...any network transport protocol may be used", it may not be possible to add/remove NSH Headers within specific transport encapsulations...but that is not discussed. Again, I think that was the intent. The design of the document (present options, but don't dig deep into any of them) is ok. It would be nicer if the WG would move this work forward by exploring the options, specifying them and having detailed operational considerations related to "the difficult problem of implementing SFC" and how hSFC may help. But I didn't find related work in the datatracker. In the end, I believe that this document is valuable as a discussion piece which may lead to future work...but, in my opinion, it doesn't need to be published as an RFC to serve that purpose...and it could in fact benefit from further analysis and evaluation before eventual publication reflecting *the* hSFC architecture. Given that we're at the IESG Evaluation point in the process, I won't stand in the way of publication and have chosen to ABSTAIN instead. |
2018-06-19
|
09 | Alvaro Retana | [Ballot Position Update] New position, Abstain, has been recorded for Alvaro Retana |
2018-06-13
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-06-13
|
09 | Mohamed Boucadair | New version available: draft-ietf-sfc-hierarchical-09.txt |
2018-06-13
|
09 | (System) | New version approved |
2018-06-13
|
09 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Mohamed Boucadair , Shunsuke Homma , Diego Lopez |
2018-06-13
|
09 | Mohamed Boucadair | Uploaded new revision |
2018-06-08
|
08 | Vijay Gurbani | Request for Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani. Sent review to list. |
2018-05-31
|
08 | Amy Vezza | Placed on agenda for telechat - 2018-06-21 |
2018-05-31
|
08 | Martin Vigoureux | Ballot has been issued |
2018-05-31
|
08 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-05-31
|
08 | Martin Vigoureux | Created "Approve" ballot |
2018-05-31
|
08 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-05-31
|
08 | Martin Vigoureux | Ballot writeup was changed |
2018-05-29
|
08 | Sean Turner | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Sean Turner. Sent review to list. |
2018-05-21
|
08 | Ines Robles | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Ines Robles. Sent review to list. |
2018-05-21
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-05-18
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2018-05-18
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2018-05-17
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2018-05-17
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2018-05-14
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-05-14
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-sfc-hierarchical-08, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-sfc-hierarchical-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-05-10
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2018-05-10
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2018-05-07
|
08 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ines Robles |
2018-05-07
|
08 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ines Robles |
2018-05-07
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-05-07
|
08 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-05-21): From: The IESG To: IETF-Announce CC: draft-ietf-sfc-hierarchical@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, Behcet Sarikaya , … The following Last Call announcement was sent out (ends 2018-05-21): From: The IESG To: IETF-Announce CC: draft-ietf-sfc-hierarchical@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, Behcet Sarikaya , sarikaya@ieee.org, martin.vigoureux@nokia.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Hierarchical Service Function Chaining (hSFC)) to Informational RFC The IESG has received a request from the Service Function Chaining WG (sfc) to consider the following document: - 'Hierarchical Service Function Chaining (hSFC)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-05-07
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-05-07
|
08 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2018-05-07
|
08 | Martin Vigoureux | Last call was requested |
2018-05-07
|
08 | Martin Vigoureux | Ballot approval text was generated |
2018-05-07
|
08 | Martin Vigoureux | Ballot writeup was generated |
2018-05-07
|
08 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation |
2018-05-07
|
08 | Martin Vigoureux | Last call announcement was generated |
2018-04-29
|
08 | David Dolson | New version available: draft-ietf-sfc-hierarchical-08.txt |
2018-04-29
|
08 | (System) | New version approved |
2018-04-29
|
08 | (System) | Request for posting confirmation emailed to previous authors: Mohamed Boucadair , sfc-chairs@ietf.org, Diego Lopez , Shunsuke Homma , David Dolson |
2018-04-29
|
08 | David Dolson | Uploaded new revision |
2018-04-10
|
07 | Martin Vigoureux | AD review: https://www.ietf.org/mail-archive/web/sfc/current/msg06453.html |
2018-04-10
|
07 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2018-03-21
|
07 | Amy Vezza | Shepherding AD changed to Martin Vigoureux |
2018-02-20
|
07 | Joel Halpern | 1. Summary The document shepherd is Behcet Sarikaya. The responsible Area Director is Alia Atlas. Instead of considering a single SFC control plane … 1. Summary The document shepherd is Behcet Sarikaya. The responsible Area Director is Alia Atlas. Instead of considering a single SFC control plane that can manage complete service paths from one end of the network to the other, the document adopts an approach that decomposes large networks into smaller domains operated by as many SFC sub-domains (under the same administrative entity). This approach is called: Hierarchical Service Function Chaining (hSFC) 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. Another goal of the hierarchical approach is to simplify the mechanisms of scaling in and scaling out service functions (SFs). All of the complexities of load-balancing among multiple SFs can be handled within a sub-domain, under control of the classifier, allowing the higher-level domain to be oblivious to the existence of multiple SF instances. The document is informational. It formulates the problem and identifies viable options to achieve hSFC. For example, this document describes how nesting NSH headers, i.e. NSH-in-NSH functionality hinted in RFC8300 is used. 2. Review and Consensus Two WGLCs were made for this document. The second one was mainly to confirm that the comments raised during the first call are well addressed. There seems to be consensus in the working group that the document is ready for publication. 3. Intellectual Property There are no known IPR disclosures on the document. Each of the authors has confirmed that they are not familiar with any IPR that applies to this document, in conformance with BCPs 78 and 79. 4. Other Points No IANA action is requested by the document. |
2018-02-20
|
07 | Joel Halpern | Responsible AD changed to Alia Atlas |
2018-02-20
|
07 | Joel Halpern | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-02-20
|
07 | Joel Halpern | IESG state changed to Publication Requested |
2018-02-20
|
07 | Joel Halpern | IESG process started in state Publication Requested |
2018-02-20
|
07 | Joel Halpern | Intended Status changed to Informational from None |
2018-02-20
|
07 | Behcet Sarikaya | Changed document writeup |
2018-02-20
|
07 | Behcet Sarikaya | Changed document writeup |
2018-02-19
|
07 | Joel Halpern | Notification list changed to Behcet Sarikaya <sarikaya@ieee.org> |
2018-02-19
|
07 | Joel Halpern | Document shepherd changed to Behcet Sarikaya |
2018-02-18
|
07 | Mohamed Boucadair | New version available: draft-ietf-sfc-hierarchical-07.txt |
2018-02-18
|
07 | (System) | New version approved |
2018-02-18
|
07 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Mohamed Boucadair , sfc-chairs@ietf.org, Shunsuke Homma , Diego Lopez |
2018-02-18
|
07 | Mohamed Boucadair | Uploaded new revision |
2018-01-18
|
06 | David Dolson | New version available: draft-ietf-sfc-hierarchical-06.txt |
2018-01-18
|
06 | (System) | New version approved |
2018-01-18
|
06 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Mohamed Boucadair , Shunsuke Homma , Diego Lopez |
2018-01-18
|
06 | David Dolson | Uploaded new revision |
2017-11-13
|
05 | David Dolson | New version available: draft-ietf-sfc-hierarchical-05.txt |
2017-11-13
|
05 | (System) | New version approved |
2017-11-13
|
05 | (System) | Request for posting confirmation emailed to previous authors: Vu Vu , sfc-chairs@ietf.org, Ting Ao , Mohamed Boucadair , Diego Lopez , Dapeng Liu , … Request for posting confirmation emailed to previous authors: Vu Vu , sfc-chairs@ietf.org, Ting Ao , Mohamed Boucadair , Diego Lopez , Dapeng Liu , David Dolson , Shunsuke Homma |
2017-11-13
|
05 | David Dolson | Uploaded new revision |
2017-07-17
|
04 | David Dolson | New version available: draft-ietf-sfc-hierarchical-04.txt |
2017-07-17
|
04 | (System) | New version approved |
2017-07-17
|
04 | (System) | Request for posting confirmation emailed to previous authors: Ting Ao , Vu Vu , Mohamed Boucadair , Diego Lopez , Dapeng Liu , David Dolson … Request for posting confirmation emailed to previous authors: Ting Ao , Vu Vu , Mohamed Boucadair , Diego Lopez , Dapeng Liu , David Dolson , Shunsuke Homma |
2017-07-17
|
04 | David Dolson | Uploaded new revision |
2017-06-30
|
03 | David Dolson | New version available: draft-ietf-sfc-hierarchical-03.txt |
2017-06-30
|
03 | (System) | New version approved |
2017-06-30
|
03 | (System) | Request for posting confirmation emailed to previous authors: Ting Ao , Vu Vu , Mohamed Boucadair , Diego Lopez , Dapeng Liu , David Dolson … Request for posting confirmation emailed to previous authors: Ting Ao , Vu Vu , Mohamed Boucadair , Diego Lopez , Dapeng Liu , David Dolson , Shunsuke Homma |
2017-06-30
|
03 | David Dolson | Uploaded new revision |
2017-01-13
|
02 | David Dolson | New version available: draft-ietf-sfc-hierarchical-02.txt |
2017-01-13
|
02 | (System) | New version approved |
2017-01-13
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Shunsuke Homma" , "Vu Vu" , "Diego Lopez" , "Ting Ao" , "David Dolson" , sfc-chairs@ietf.org, … Request for posting confirmation emailed to previous authors: "Shunsuke Homma" , "Vu Vu" , "Diego Lopez" , "Ting Ao" , "David Dolson" , sfc-chairs@ietf.org, "Mohamed Boucadair" , "Dapeng Liu" |
2017-01-13
|
02 | David Dolson | Uploaded new revision |
2016-09-13
|
01 | David Dolson | New version available: draft-ietf-sfc-hierarchical-01.txt |
2016-09-13
|
01 | David Dolson | New version approved |
2016-09-13
|
01 | David Dolson | Request for posting confirmation emailed to previous authors: "Shunsuke Homma" , "Diego Lopez" , "Vu Anh Vu" , "Ting Ao" , "David Dolson" , sfc-chairs@ietf.org … Request for posting confirmation emailed to previous authors: "Shunsuke Homma" , "Diego Lopez" , "Vu Anh Vu" , "Ting Ao" , "David Dolson" , sfc-chairs@ietf.org, "Mohamed Boucadair" , "Dapeng Liu" |
2016-09-13
|
01 | (System) | Uploaded new revision |
2016-07-26
|
00 | Jim Guichard | This document now replaces draft-dolson-sfc-hierarchical instead of None |
2016-07-26
|
00 | David Dolson | New version available: draft-ietf-sfc-hierarchical-00.txt |