Adrian, et al,
I understand that this is chair's call and will certainly respect their
decision.
For what it worth, I would just like to point out that we are talking about a
substantial amount of changes and the support votes may have been influence by
the contents authors kindly agreed to remove.
Thanks
Regards … Zafar
On 3/17/18, 4:02 AM, "sfc on behalf of Adrian Farrel" <sfc-boun...@ietf.org on
behalf of adr...@olddog.co.uk> wrote:
Zafar,
The authors will surely post a new version.
Adoption is now, and always has been, a matter for the chairs. We are putty
in their hands.
As to your judgement of "lack of support", I snorted when I read your
comment. I may have startled the other people on the train. I think you know
how the IETF consensus process works and who gets to call it, but just in case,
you may find RFC 7282 helpful.
Ciao,
Adrian
--
Support an author and your imagination
Tales from the Wood - Eighteen new fairy tales
More Tales from the Wood - Eighteen MORE new fairy tales
Tales from Beyond the Wood - A bumper collection of twenty-two new tales
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct at IETF-101
> -----Original Message-----
> From: Zafar Ali (zali) [mailto:z...@cisco.com]
> Sent: 17 March 2018 07:09
> To: adr...@olddog.co.uk; m...@ietf.org; s...@ietf.org; 'SPRING WG List'
> Subject: Re: [mpls] Progress with draft-farrel-mpls-sfc
>
> Hi Adrian, et al,
>
> Thanks for addressing the concerns and responding to the objections to the
> draft.
>
> Given the amount and nature of the expected changes and lack of support, I
> would assume authors will resubmit and ask for WG adaptation on a revised
> revision.
>
> Thanks
>
> Regards … Zafar
>
> On 3/16/18, 5:12 PM, "mpls on behalf of Adrian Farrel"
<mpls-boun...@ietf.org
> on behalf of adr...@olddog.co.uk> wrote:
>
> All,
>
> The authors of draft-farrel-mpls-sfc have listened carefully to the
reviews and
> comments starting with MPLS-RT reviews, continuing through the debate
on
> various
> mailing lists, and including private emails sent to some of us.
>
> We see three points to address:
>
> 1. Discussion of Segment Routing
>
> In retrospect we should not have mentioned SR in this document.
That's my
> fault
> and I'm sorry: I was trying too hard to get a document posted and to
achieve
> convergence with other ideas that had been floated, and I was not
thinking
> clearly.
>
> Our plan is to remove all discussion of SR (specifically MPLS-SR)
from this
> document. That will leave a document that talks only about the MPLS
data
> plane
> (as already defined with only the normal label operations of push,
pop, and
> swap) and the use of labels to encode the information included in the
NSH.
>
> 2. What is the purpose of MPLS SFC?
>
> I'm a bit surprised that we did not state this clearly in the
document. There is
> some text but it is neither clear nor prominent.
>
> I think that what happened was that *we* knew why we were writing it,
and
> we
> discussed the point with the SFC chairs, but we never wrote it down.
>
> That needs to be fixed in the Abstract and the Introduction.
>
> For the record: This document describes how Service Function
Chaining can
> be
> achieved in an MPLS network by means of a logical representation of
the NSH
> in
> an MPLS label stack. It does not deprecate or replace the NSH, but
> acknowledges
> that there may be a need for an interim deployment of SFC
functionality in
> brownfield networks. The mechanisms described are a compromise between
> the full
> function that can be achieved using the NSH, and the benefits of
reusing the
> existing MPLS forwarding paradigms.
>
> 3. Support for SFs that do not handle MPLS
>
> There is, in our opinion no difference between an SF that does not
handle the
> NSH in RFC 8300 and an SF that does not handle MPLS in this document.
Both
> need
> to use an SFC Proxy as described in this document.
>
> We already have a section on SFC Proxies, but it is late in the
document. We
> should fix that by highlighting the issue in the Introduction and
pointing to
> the later section.
>
> Thanks,
> Adrian (in consultation with the co-authors)
>
> _______________________________________________
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
_______________________________________________
sfc mailing list
s...@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
