Subject: [sfc] WG Last call - Hierarchical SFC

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Mar 2017 14:30:29 -0400

This is a last call for:
https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02

Please respond to the list as to whether you see problems with this, you 
think it is done, or any other input for the WG.

Due to the run up to the IETF, we will let this run until April 7.

Yours,
Joel & Jim

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Mar 2017 19:42:58 -0000

All,

I'm not very excited by hSFC. So far we haven't been able to come up
with examples of very long chains and while they may one day be found
it seems premature to do work on hSFC. I do agree that the use cases
shown can be solved with hSFC, but I also don't see use cases as 
insoluble using other approaches.

So please take this as a "publish it if you must" level of support :-)

But anyway, here are a few comments from reading the latest revision.

Cheers,
Adrian

Seven authors will probably give the AD heartburn.

---

I'm surprised to see this last called when it has normative references
to one document that the still needs work before it can go to a second
WG last call, and another document that the WG is debating abandoning.

---

The introduction contains the reasonable note...
      Note: in this document, the notion of the "path" of a packet is
      the series of SF instances traversed by a packet.  The means of
      delivering packets between SFs (i.e., the forwarding mechanisms
      enforced in the underlying network) are not relevant to the
      discussion.
Why, then, does the document go on to discuss SFFs?

---

We were explicitly told in the WG that an SFF cannot make assumptions 
based on the transport tunnel used to deliver a packet to the SFF.

3.1.1 seems to be counter to this.

I would be happy to hear that 3.1.1 is a valid approach, but if so then
the WG needs to agree that an SFF *can* make determinations based on the
transport tunnel. In particular, it can tell whether a packet has 
arrived from another SFF, from an SF, or from a classifier.

---

It is all very well for section 3.1 to describe 5 perfectly achievable
approaches to hSFC, but in order to achieve interop, the head and tail
ends of a lower layer SFC need to use the same mechanism. That means
that the mechanism either has to be determined through the control plane
or exposed by examination of the data plane. Furthermore, the 
implication is that all implementations have to support all five 
mechanisms.

Saying that this document "sets expectations for control planes" is
all very well, but by keeping so many options and punting on the details
you are making it unlikely that a workable solution will be 
standardised.

Following the principle that "options are bad" can't we manage to cut
this list down to just one method (or worst case, two)?

Why do we need five mechanisms?

(I note that option 3 is "free" with reclassification, while option 4
is already defined in the NSH spec.)

---

Section 9.2 seems to be out of date.
Indeed, some of the hSFC approaches here include "reclassification" in 
a way that would stop the SI being used to detect loops. So we need to
invoke the TTL. But how will the TTL be used? Will the lower layer SPF
inherit the TTL from the higher layer, or will it reset it? Will the
higher layer SFP be updated according to the TTL of the lower layer?
Can two lower layer SFPs be stitched together without a "hop" in the 
higher layer?

More work needed on loops, I think.

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 14 March 2017 18:30
> To: [email-masked]
> Subject: [sfc] WG Last call - Hierarchical SFC
> 
> This is a last call for:

---

From: <[email-masked]>
Date: Wed, 15 Mar 2017 14:31:53 +0000

Hello WG,

I think the hSFC draft is in good shape and should be moved forward. 

I've also read Adrian's (introductory) comments on the draft and it seems to me that the hSFC approach isn't only meant to address potential issues raised by the operation of "long" chains, whatever makes a chain long. 

Organizational matters can be instrumental too, so that hSFC can help service providers in better mastering resource usage in various regions of a SFC domain, e.g., according to a typical access/backhaul/core taxonomy possibly distorted by the market coverage - residential/enterprise/wholesale/mobile, let alone the scope of the connectivity service associated to a given SFC: for example, IoT services that are deployed at the scale of a city or a region and which may involve specific interconnect design schemes may become iconic beneficiaries of hSFC, but that's another use case argument.

There may be other approaches that address such use cases/organizational considerations, but I think hSFC can facilitate the corresponding SFC design and operation.

Cheers,

Christian. 

-----Message d'origine-----
De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
Envoyé : mardi 14 mars 2017 19:30
À : [email-masked]
Objet : [sfc] WG Last call - Hierarchical SFC

This is a last call for:

Please respond to the list as to whether you see problems with this, you think it is done, or any other input for the WG.

Yours,
Joel & Jim

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Dave Dolson <[email-masked]>
Date: Mon, 20 Mar 2017 18:22:29 +0000

Adrian,
Thank you for reading and providing suggestions.

Please see inline comments [DD]

For those who wish to follow along or make pull requests, collaboration is occurring on github: https://github.com/dcdolson/draft-dolson-sfc-hierarchical
I'm going to track issues there.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, March 14, 2017 3:43 PM
To: 'Joel M. Halpern'; [email-masked]
Subject: Re: [sfc] WG Last call - Hierarchical SFC

All,

Cheers,
Adrian

Seven authors will probably give the AD heartburn.
[DD] Why? How is this usually handled?

---

I'm surprised to see this last called when it has normative references
to one document that the still needs work before it can go to a second
WG last call, and another document that the WG is debating abandoning.
[DD] I would expect the RFC editor to queue this behind I-D.ietf-sfc-nsh? 
[DD] As for I-D.ietf-sfc-control-plane, if it is abandoned, we need to explain some concepts within hSFC.

---

[DD] We should choose whether to make this agnostic about technology or embrace NSH.

---

[DD] It is intended that the packets are returned to the higher layer only at the *termination* of the lower-level chain. I think we can probably clarify this better by saying the IBN is about classification and termination (the start and end of chains), not the middle. Does that help?

---

Why do we need five mechanisms?
[DD] I wouldn't mind reducing this, but keep in mind that being both the start and end of the sub-domain, the IBN actually do something proprietary. Perhaps we should be defining the schemes in terms of requirements at the SFs? (e.g., supporting nested NSH, respecting reserved metadata...)  Maybe others can make suggestions.

(I note that option 3 is "free" with reclassification, while option 4
is already defined in the NSH spec.)
[DD] I don't see the IBN as doing only "reclassification". It is important that we view the sub-domain as being independently administered.

---

More work needed on loops, I think.
[DD] Waiting for I-D.ietf-sfc-nsh to be updated with the TTL. Yes, TTL propagation rules would need to be defined.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 20 Mar 2017 14:59:04 -0400

On Mon, Mar 20, 2017 at 2:22 PM, Dave Dolson <[email-masked]> wrote:

> For those who wish to follow along or make pull requests, collaboration is
> occurring on github: https://github.com/dcdolson/
> draft-dolson-sfc-hierarchical

[Alia] Except in unusual and well explained circumstances, I will not
advance
a document with more than 5 editors/authors.  This is standard IETF-wide
policy.
If there are a large number of authors, then the WG Chairs usually encourage
appointing one or two editors and the remainder are thanked as contributors.

Regards,
Alia

> [DD] It is intended that the packets are returned to the higher layer only
> at the *termination* of the lower-level chain. I think we can probably
> clarify this better by saying the IBN is about classification and
> termination (the start and end of chains), not the middle. Does that help?
>
>
> ---
>
> [DD] I wouldn't mind reducing this, but keep in mind that being both the
> start and end of the sub-domain, the IBN actually do something proprietary.
> Perhaps we should be defining the schemes in terms of requirements at the
> SFs? (e.g., supporting nested NSH, respecting reserved metadata...)  Maybe
> others can make suggestions.
>
> [DD] I don't see the IBN as doing only "reclassification". It is important
> that we view the sub-domain as being independently administered.
>
> ---
>
> [DD] Waiting for I-D.ietf-sfc-nsh to be updated with the TTL. Yes, TTL
> propagation rules would need to be defined.
>
>
>