Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-serviceid-header

[<[e-mail]>]

Hi Qin,
Thanks for your valuable comments. We agree that there are other ways to do SFC control but classified them as out of scope here – and decided to delete the pointer to sfc-control-plane draft since it was expired.
The draft says:
==
    The semantics and validation of these
    identifiers are up to the control plane used for SFC.  Expectations
    to SFC control plane protocols are laid down, e.g., in [RFC8459], but
    specifications of SFC control plane functions are also discussed in,
    for example, [I-D.ietf-bess-nsh-bgp-control-plane].  Control plane
    related considerations are out of scope.
==
Also we already mentioned some examples as e.g. UHR/ULL services foreseen for 5G or in the text as follows:
==
   The context information defined in this document can be applicable in
   the context of mobile networks (typically, in the 3GPP defined (S)Gi
   Interface) [I-D.ietf-sfc-use-case-mobility].  Because of the
   widespread use of private addressing in those networks, if SFs to be
   invoked are located after a NAT function (that can reside in the
   Packet Data Network (PDN) Gateway (PGW) or in a distinct node), the
   identification based on the internal IP address is not possible once
   the NAT has been crossed.  As such, means to allow passing the
   internal information may optimise packet traversal within an SFC-
   enabled mobile network domain.  Furthermore, some SFs that are not
   enabled on the PGW may require a subscriber identifier to properly
   operate.  It is out of scope of this document to include a
   comprehensive list of deployment contexts which may make use of the
   context headers defined in the document.
==
Of course we can extend it in an appendix. There we could also mention typical exemplary Subscriber IDs already in use at e.g. 3GPP level …
Do you think it would help?
Thanks again!
Kind regards – also on behalf of co-authors
Dirk
> -----Original Message-----
> From: sfc <[e-mail]<mailto:[e-mail]>> On Behalf Of Qin Wu
> Sent: Montag, 16. Dezember 2019 05:11
> To: Joel M. Halpern <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-serviceid-
> header
>
> Joel, thanks for your clarification.
> My argument is SFC control plane is one relevant work, SFC control plane
> can be centralized or distributed based on section 3.2 of SFC control plane
> draft.
> It doesn't recommend any mechanism since it is just architecture draft.
>
> I can live with this draft moving forward without this reference, but I
> don't buy your reason given below.
>
> -Qin
> > -----邮件原件-----
> > 发件人: Joel M. Halpern [mailto:[e-mail]<mailto:[e-mail]>]
> > 发送时间: 2019年12月16日 9:27
> > 收件人: Qin Wu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> > 主题: Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-serviceid-
> > header
> >
> > I am not confident that I follow your reasoning.   So let me restate
> > slightly, and then add some observations and questions.
> >
> > You appear to be observing that the information as to what serviceID
> could
> > come from the control plane framework.  Is that what you are getting at?
> >
> > That draft has not been updated in more than 3 years, expired for 2.5
> > years.  It does not appear that the working group has any interest in the
> > document.  When it was last considered, there was a lot of controversey
> > about the draft, and if I recall correctly no agreement that it was
> > structured the right way.
> >
> > Our approach to metadata, and for that matter to SPFID selection, and to
> > the forwarding entries in SFF, has been that the information can come
> from
> > a number of places and we do not tie the definitions to the mechanisms
> used
> > to provide them.
> >
> > As such, I do not understand what form of reference would be appropriate,
> > even if the cited document were an active WG document.
> >
> > Yours,
> > Joel
> >
> > On 12/15/2019 8:07 PM, Qin Wu wrote:
> > > I believe this draft is under umbrella of draft-ietf-sfc-control-plane-
> > 08, suggest to add reference to it.
> > > In addition, It will be great to add usage example of new defined
> > subscriber identifier and Performance Policy Identifier.
> > > Besides these, I think this draft is ready to go.
> > >
> > > -Qin
> > > -----邮件原件-----
> > > 发件人: sfc [mailto:[e-mail]<mailto:[e-mail]>] 代表 Joel M. Halpern
> > > 发送时间: 2019年12月11日 21:52
> > > 收件人: [e-mail]<mailto:[e-mail]>
> > > 主题: [sfc] Fwd: IETF WG state changed for
> > > draft-ietf-sfc-serviceid-header
> > >
> > > Starting WG Last call.  See comment below for description.
> > > Thank you,
> > > Joel
> > >
> > >
> > > -------- Forwarded Message --------
> > > Subject: IETF WG state changed for draft-ietf-sfc-serviceid-header
> > > Resent-Date: Tue, 10 Dec 2019 09:27:51 -0800 (PST)
> > > Resent-From: [e-mail]<mailto:[e-mail]>
> > > Resent-To: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>,
> > > [e-mail]<mailto:[e-mail]>
> > > Date: Tue, 10 Dec 2019 09:27:51 -0800
> > > From: IETF Secretariat <[e-mail]<mailto:[e-mail]>>
> > > To: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
> > >
> > >
> > > The IETF WG state of draft-ietf-sfc-serviceid-header has been changed
> > > to "In WG Last Call" from "WG Document" by Joel Halpern:
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/
> > >
> > > Comment:
> > > This starts the working group last call for this document.  It has
> > > been discussed on the email list.  We need to see responses.  If you
> > > see issues with publishing this document as an RFC, please speak up
> now.
> > And please be
> > > clear about what your concerns are.   At the same time, if you think
> that
> > > publishing this as an RFC is a good thing for the working group,
> > > please speak up.
> > >
> > > As a note for those who may be concerned about the relationship to the
> > > TLV draft, the chairs have noticed that problem, and we believe we
> > > have gotten that document unstuck.
> > >
> > > Given the propensity for people to disappear at this time of year, I
> > > am giving the document a 4 week last call.
> > >
> > > Thank you for your time and attention, Joel (& Jim)
> > >
> > > _______________________________________________
> > > sfc mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/sfc
> > >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/sfc