Re: [sfc] WG Last call - Hierarchical SFC

[Alia Atlas <[e-mail]>]

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

> 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:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, March 14, 2017 3:43 PM
> To: 'Joel M. Halpern'; [e-mail]
> Subject: Re: [sfc] WG Last call - Hierarchical SFC
>
> 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.
> [DD] Why? How is this usually handled?
>

[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


> ---
>
> 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.
>
> ---
>
> 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?
> [DD] We should choose whether to make this agnostic about technology or
> embrace NSH.
>
> ---
>
> 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.
>
> [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?
>
>
> ---
>
> 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?
> [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.
>
> ---
>
> 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.
> [DD] Waiting for I-D.ietf-sfc-nsh to be updated with the TTL. Yes, TTL
> propagation rules would need to be defined.
>
>
>
> > -----Original Message-----
> > From: sfc [mailto:[e-mail]] On Behalf Of Joel M. Halpern
> > Sent: 14 March 2017 18:30
> > To: [e-mail]
> > Subject: [sfc] WG Last call - Hierarchical SFC
> >
> > 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.
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>