Hi, Adrian, Thanks for responding to my comments. Your explanation is reasonable to me. One more irrelevant question: maybe you could make the Controller term definition in this document, then the other future documents may reference to it? It may help to solve the situation that we will always talk about Controller, but do not have a definition or term reference for years. Best regards, Sheng > -----Original Message----- > From: Adrian Farrel [mailto:adrian@xxxxxxxxxxxx] > Sent: Monday, December 16, 2019 5:18 PM > To: Sheng Jiang <jiangsheng@xxxxxxxxxx>; ops-dir@xxxxxxxx > Cc: last-call@xxxxxxxx; bess@xxxxxxxx; > draft-ietf-bess-nsh-bgp-control-plane.all@xxxxxxxx > Subject: RE: Opsdir last call review of draft-ietf-bess-nsh-bgp-control-plane-13 > > Thanks for this review. > > I see you were looking at the -13 revision which is the most recent. > > Per Brian Carpenter's GenArt review of -12 we added some text to clarify > "controller". > Section 1 > a > Controller (a centralized network component responsible for planning > and coordinating Service Function Chaining within the network) Section 2.1 > An essential component of this solution is the > Controller. This is a network component responsible for planning > SFPs within the network. It gathers information about the > availability of SFIs and SFFs, instructs the control plane about the > SFPs to be programmed, and instructs the Classifiers how to assign > traffic flows to individual SFPs. > > I don't think this Controller is an "SDN Controller" according to the two references > you suggest. Indeed, the assumption in this document is that an active control > plane is in use which is somewhat against the assumptions of the documents you > point to. You could say that this Controller is more akin to a stateful PCE, but I > don't even want to make that comparison in this document because the use of a > PCE normally implies the presence of PCEP. > > In short, I think that the text we have to describe a Controller, combined with the > various explanations throughout the document that say what a Controller does, > are enough to make the term contained within this document. > > > You're right about the downrefs. > > 7665 is, I think, established as a permissible downref. It has been used multiple > times, although it is not listed at > https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry > > 8596 caught me by surprise. I don't understand why it is not Standards Track. It > uses 2119 language and describes how to implement/interop. > > I think I'll leave this to the AD to worry about! > > > Best, > Adrian > > -----Original Message----- > From: Sheng Jiang via Datatracker <noreply@xxxxxxxx> > Sent: 16 December 2019 08:17 > To: ops-dir@xxxxxxxx > Cc: last-call@xxxxxxxx; bess@xxxxxxxx; > draft-ietf-bess-nsh-bgp-control-plane.all@xxxxxxxx > Subject: Opsdir last call review of draft-ietf-bess-nsh-bgp-control-plane-13 > > Reviewer: Sheng Jiang > Review result: Has Issues > > Reviewer: Sheng Jiang > Review result: Has Issues > > Reviewer: Sheng Jiang > Review result: Has Issues > > Hi, OPS-DIR, Authors, > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in last call may be included in > AD reviews during the IESG review. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This standard track document describes the use of BGP as a control plane for > networks that support SFC with newly defined BGP Parameters, BGP AF/SAF, > BGP Path Attribute , SFP Attribute TLVs Type Registry, SFP Association Type > Registry and Service Function Type Registry. > > This document is clear and well written. > > Minor issues: > > However, I do have an issue with the terminology controller in this document. > Although the community seems knowing the SDN controller concepts well. There > is no well-defined terminology for it. Therefore, this document are missing the > most fundamental reference. The below three RFCs are potential references for > the terminology, but still not the best suitable one, and they are all Informational > RFCs, which is Downref in this context: > > RFC 7426: Software-Defined Networking (SDN): Layers and Architecture > Terminology RFC 8455: Terminology for Benchmarking Software-Defined > Networking (SDN) Controller Performance RFC 8456: Benchmarking Methodology > for Software-Defined Networking (SDN) Controller Performance > > And this document has already had two Downref RFC 7665, RFC 8596 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
