Re: [sfc] sfc Digest, Vol 29, Issue 32

[Sunjai Chalikar <[e-mail]>]

I am an IETF privileged member and have invented IPv8 > Varied Layer
Wireless Protocol with 1024 bits of security. pls members of IETF revert
back .

I am the President & CTO from Peon Level> of my own company named Cisnet
Systems + Solutions from India.

Also, I have invented CETA bits or bytes after 1trillion of Zetabytes.
happy going. Just if u all could spare some time to me checkout my 3
personal websites stated below:

http://cisnetsolutions.yolasite.com, http://bramhastra.yolasite.com,
http://cisnetsystems.yolasite.com.

and my experience sheet is attached.


cheers,
Mr. Chalikar Sanjay
Skype ID: sanjay.chalikare

+91 - 9637 436287/
[e-mail]/ [e-mail]/ [e-mail]/

http://lnkd.in/sJm_yE
http://www.linkedin.com/pub/sanjay-chalikar/2b/7a3/13a


On Thu, Oct 29, 2015 at 10:38 PM, <[e-mail]> wrote:

> Send sfc mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/sfc
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sfc digest..."
>
> Today's Topics:
>
>    1. SFC Agenda for Yokohoma (Thomas Narten)
>    2. Re: SFC WG agenda slots - Yokohama (Kengo NAITO)
>    3. Re: New Version Notification for
>       draft-xu-sfc-using-mpls-spring-04.txt (Xuxiaohu)
>    4. Re: FW: New Version Notification for
>       draft-aranda-sf-dp-mobile-00.txt ([e-mail])
>
>
> ---------- Forwarded message ----------
> From: Thomas Narten <[e-mail]>
> To: [e-mail]
> Cc:
> Date: Wed, 28 Oct 2015 16:04:10 -0400
> Subject: [sfc] SFC Agenda for Yokohoma
> The agenda for Yokohama is been posted at the usual places. E.g.,
>
>     Sfc Status Pages
>     http://tools.ietf.org/wg/sfc/agenda
>
> I've included the current contents below.
>
> If you are a presenter please plan to send Jim & I slides no later
> than Monday 11/2 so that we have time to review and post prior to the
> meeting.
>
> Thomas & Jim
>
>
> IETF-94 sfc agenda
> Session 2015-11-05 0900-1130: Room 502 - Audio stream - sfc chatroom
>
> Agenda
>
>
>
>
>           IETF94 Yokohama SFC Agenda
>           Total time: 2.5 hours
>
>           00:00 Introduction (WG-chairs) - [5 minutes]
>                    Agenda bashing, note-well, (WG-chairs) - [5 minutes]
>
>           00:05 SFC Security Requirements (Presenter + open-mic) - [25
> minutes]
>
>                   - SFC Environment Security Requirements (Daniel Migault)
> - [15 minutes]
>                           -
> http://www.ietf.org/id/draft-mglt-sfc-security-environment-req-00.txt
>
>                   - SFC Security Requirements Q&A (open-mic) - [10 minutes]
>
>
>           00:30 SFC Use Cases (Presenters + open-mic) - [40 minutes]
>
>                   - SFC Use Cases in Mobile Networks (Jeff Napper) - [10
> minutes]
>                           -
> https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/
>
>                   - SFC Use Cases for Network Security (Eric Wang) - [10
> minutes]
>                           -
> https://www.ietf.org/internet-drafts/draft-wang-sfc-ns-use-cases-00.txt
>
>                   - SFC Use Cases in Broadband (Wei Meng) - [10 minutes]
>                           -
> https://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/
>
>                   - SFC Use Cases Q&A (open-mic) - [10 minutes]
>
>
>           01:10 SFC Architecture Items (Presenters + open-mic) - [50
> Minutes]
>
>                   - UDP Overlay Transport For Network Service Header
> (Surendra Kumar) - [10 minutes]
>                           -
> https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-transport/
>
>                   - Map Assisted SFC Proxy using LISP (Albert Cabellos) -
> [10 minutes]
>                           -
> https://datatracker.ietf.org/doc/draft-cabellos-sfc-map-assisted-proxy/
>
>                   - Packet Generation in Service Function Chains (Reinaldo
> Penno) - [10 minutes]
>                           -
> https://datatracker.ietf.org/doc/draft-penno-sfc-packet/
>
>                   - Hierarchical Service Function Chaining (Dave Dolson) -
> [10 minutes]
>                           -
> https://datatracker.ietf.org/doc/draft-dolson-sfc-hierarchical/
>
>                   - SFC Architecture Items Q&A (open-mic) - [10 minutes]
>
>           02:00 SFC Miscellaneous (Presenters + open-mic) - [25 minutes]
>
>                   - SFC Trace Issue Analysis & Solutions (Lei Zhu) - [10
> minutes]
>                           -
> https://datatracker.ietf.org/doc/draft-yang-sfc-trace-issue-analysis/
>
>                   - SFC: Subscriber & Host Identification Considerations
> (TBD) - [10 minutes]
>                           -
> https://datatracker.ietf.org/doc/draft-sarikaya-sfc-hostid-serviceheader/
>
>                   - SFC Miscellaneous Q&A (open-mic) - [5 minutes]
>
>
>           02:25 Closing (WG-chairs) - [5 minutes]
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Kengo NAITO <[e-mail]>
> To: "Jim Guichard (jguichar)" <[e-mail]>
> Cc: katsuhiro horiba <[e-mail]>, "[e-mail]" <[e-mail]>,
> "久保聡之" <[e-mail]>, Ayumu Yasuda <[e-mail]>,
> "久保聡之" <[e-mail]>, Sekiya Yuji <[e-mail]>,
> "本間俊介" <[e-mail]>
> Date: Thu, 29 Oct 2015 09:02:45 +0900
> Subject: Re: [sfc] SFC WG agenda slots - Yokohama
> Hello Jim & Thomas,
>
> I and some members from NSP consortium (which is one of the big
> organization in Japan who tests all kinds of network virtualization
> technologies) formed a team to test a running-code of SFC Proxy at the IETF
> hackathon.
>
> https://www.ietf.org/registration/MeetingWiki/wiki/94hackathon
>
> We would like to introduce our work to SFCers, and would like to ask you
> if we can have a slot at SFC meeting in Yokohama.
> I believe our work would be one good reference to improve SFC.
>
> Best Regards,
> Kengo
>
> ------------------------------------------------
> Kengo NAITO
> Technology Development
> NTT Communications Corporation
> Tel: [phone]
> E-mail: [e-mail]
> ------------------------------------------------
>
> > 2015/10/05 21:51、Jim Guichard (jguichar) <[e-mail]> のメール：
> >
> > Greetings WG:
> >
> > Our meeting in Yokohama is fast approaching. As always the goal of the
> meeting will be to make the best use of our limited face-to-face time. With
> that in mind we welcome requests for agenda time.
> >
> > As we build the meeting agenda our goal will be to select presentations
> that best further the work of the WG, and that generally means focusing on
> key charter deliverables and topics with important open issues to resolve.
> When making a request please consider what you think the WG should do with
> its content – for example:
> >       • Does the document have useful content that should be moved into
> another WG document or progress on its own merit
> >       • Does the content have a good basis for one of the WG documents
> per the charter
> >       • Should the document content be merged with one or more other
> documents, so that a combined document could become a WG document
> > Jim & Thomas
> > _______________________________________________
> > sfc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sfc
>
>
>
>
> ---------- Forwarded message ----------
> From: Xuxiaohu <[e-mail]>
> To: Thomas Narten <[e-mail]>
> Cc: "'[e-mail]'" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "'[e-mail]'" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> Date: Thu, 29 Oct 2015 01:40:38 +0000
> Subject: Re: [sfc] New Version Notification for
> draft-xu-sfc-using-mpls-spring-04.txt
> Hi Thomas,
>
> > -----Original Message-----
> > From: Thomas Narten [mailto:[e-mail]]
> > Sent: Thursday, October 29, 2015 12:22 AM
> > To: Xuxiaohu
> > Cc: '[e-mail]'; [e-mail]; '[e-mail]';
> > [e-mail]
> > Subject: Re: New Version Notification for
> draft-xu-sfc-using-mpls-spring-04.txt
> >
> > Hi Xiaohu.
> >
> > See below.
> >
> > > I haven't received any response from you yet. Would you please tell us
> > > your thoughts on the new version of this draft. Thanks a lot.
> >
> > > Best regards, Xiaohu (on behalf of all co-authors)
> > >
> > > > -----Original Message----- From: Xuxiaohu Sent: Wednesday, September
> > > > 09,
> > > > 2015 5:45 PM To: '[e-mail]'; [e-mail] Cc:
> > > > '[e-mail]'; [e-mail] Subject: FW: New Version
> > > > Notification for draft-xu-sfc-using-mpls-spring-04.txt
> > > >
> > > > Hi all,
> > > >
> > > > Service chaining is an important function for all type of networks
> > > > including those using the source routing paradigm as specified by
> > > > the SPRING working group.  This draft is especially focused on the
> > > > SPRING/MPLS network scenario.
> >
> > > > When we posted the early versions (-00 to -02), the feedback from
> > > > the SFC working group chairs was that the solution required changes
> > > > to the MPLS architecture. We discussed this among the authors and
> > > > posted a new version
> > > > (-03) that does not require any change to the MPLS Architecture
> anymore.
> > > > Version -04 merely corrects some typos.
> >
> > Good that the document is now consistent with the MPLS architecture.
> >
> > That said, this document is not really core to SFC. E.g., we are focused
> on being
> > transport independent. This document is MPLS-specific.
>
> In this draft, the SFC encapsulation is implemented in the form of an MPLS
> label stack (equivalent to NSH). Such SFC encapsulation could be
> transported over any transport networks such as IPv4, IPv6, MPLS networks.
> In a words, the SFC-encapsulation approach described in this draft is fully
> transport-independent indeed.
>
> > The key question is how relevant and important it is to the work of this
> WG. Our
> > read of the mailing list discussions over recent months is that there
> isn't strong
> > interest in this work.
>
> By encoding the SFP info by an MPLS label stack (i.e., implementing the
> SFC encapsulation in the form of an MPLS label stack), SFF devices could be
> easily implemented on existing MPLS devices without any change to their
> data planes. As a result, there is no need to introduce a totally new SFC
> encapsulation scheme and accordingly there is no need to introduce a
> totally new forwarding paradigm (e.g., NSH-based forwarding paradigm)
> especially when considering implementing SFFs on hardware platforms due to
> performance demands.
>
> According to the following statement quoted from the current SFC charter:
>
> "... The WG will examine existing identifier schemes,
>   if there is a need for such identifiers in the context of the Generic SFC
>   encapsulation, before defining any new identifier scheme.
> ..."
>
> It seems that this MPLS-SPRING-based SFC encapsulation scheme should be
> relevant to the SFC WG. At least, it could be investigated as a
> light-weight SFC encapsulation approach (from the aspect of reducing and
> even avoiding any impact on the data plane).
>
> Best regards,
> Xiaohu
>
> > Given the weak interest and lack  of clear importance to the WG core
> > deliverables, we do not see justification for taking this on as a WG
> document.
> >
> > Thomas & Jim
> >
> >
> > > > Now we would like to ask the SFC chairs and WGs if the draft can now
> > > > be considered for adoption by the SFC working group.
> >
> >
> >
> > > >
> > > > Best regards, Xiaohu
> > > >
> > > > > -----Original Message----- From: [e-mail]
> > > > > [mailto:[e-mail]] Sent: Wednesday, September 09,
> > > > > 2015 5:23 PM To: Lizhenbin; Luis M. Contreras; Xuxiaohu; Himanshu
> > > > > C. Shah; Xuxiaohu; Himanshu Shah; Luis M. Contreras; Lizhenbin
> > > > > Subject: New Version Notification for
> > > > > draft-xu-sfc-using-mpls-spring-04.txt
> > > > >
> > > > >
> > > > > A new version of I-D, draft-xu-sfc-using-mpls-spring-04.txt has
> > > > > been successfully submitted by Xiaohu Xu and posted to the IETF
> > > > repository.
> > > > >
> > > > > Name: draft-xu-sfc-using-mpls-spring Revision: 04 Title: Service
> > > > > Function Chaining Using MPLS-SPRING Document date: 2015-09-09
> > > > > Group: Individual Submission Pages: 7 URL:
> > > > > https://www.ietf.org/internet-drafts/draft-xu-sfc-using-mpls-sprin
> > > > > g-04
> > > > > .txt Status:
> > > > > https://datatracker.ietf.org/doc/draft-xu-sfc-using-mpls-spring/
> Htmlized:
> > > > > https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-04
> Diff:
> > > > > https://www.ietf.org/rfcdiff?url2=draft-xu-sfc-using-mpls-spring-0
> > > > > 4
> > > > >
> > > > > Abstract:
> > > > >    Source Packet Routing in Networking (SPRING) WG specifies a
> special
> > > > >    source routing mechanism.  Such source routing mechanism can be
> > > > >    leveraged to realize the service path layer functionality of the
> > > > >    service function chaining (i.e, steering traffic through a
> particular
> > > > >    service function path) by encoding the service function path or
> the
> > > > >    service function chain information as the explicit path
> information.
> > > > >    This document describes how to leverage the MPLS-based source
> > routing
> > > > >    mechanism as developed by the SPRING WG to realize the service
> path
> > > > >    layer functionality of the service function chaining.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Please note that it may take a couple of minutes from the time of
> > > > > submission until the htmlized version and diff are available at
> > > > > tools.ietf.org.
> > > > >
> > > > > The IETF Secretariat
> > >
>
>
>
>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> To: <[e-mail]>, <[e-mail]>
> Cc: [e-mail]
> Date: Thu, 29 Oct 2015 18:08:08 +0100
> Subject: Re: [sfc] FW: New Version Notification for
> draft-aranda-sf-dp-mobile-00.txt
> Dear all,
> I had a look at the draft and think it would be worth to elaborate further
> on this - as already mentioned it tackles 5G issues which are expected to
> be of major interest to all mobile and 'integrated' operators.
> Maybe you might also announce the draft to the newly created 5Gangip
> discussion list (https://www.ietf.org/mailman/listinfo/5gangip) to get
> helpful feedback.
>
> First observations from my side:
>
> Why is in the title named 'Dataplane' - don't you address both DP and CP
> functions to be virtualized?
>
> Sect. 1.3. and ch. 4 are very much similar ... this might be shortened.
>
> In Ch. 2 shouldn't it read
> As the specifications mature, we will provide the updates to the _evolved_
> LTE _-A/5G_ architecture. ?
>
> Some nits found in sect.
>  1.4:
> i) Medium Access Control (MAC) => ii) Medium Access Control (MAC)
>
> 2.1:
> act on user traffic may depend not only depend on subscriber =>  act on
> user traffic may depend not only on subscriber
>
> 3:
> We except the RRC to be integrated => We expect the RRC to be integrated
>
>
> Thanks and Best Regards
> Dirk
>
> -----Original Message-----
> From: sfc [mailto:[e-mail]] On Behalf Of Thomas Narten
> Sent: Mittwoch, 28. Oktober 2015 17:51
> To: PEDRO ANDRES ARANDA GUTIERREZ
> Cc: [e-mail]
> Subject: Re: [sfc] FW: New Version Notification for
> draft-aranda-sf-dp-mobile-00.txt
>
> On Wed, 7 Oct 2015 05:41:20 +0000, PEDRO ANDRES ARANDA GUTIERREZ wrote:
> > I’m requesting a slot to present this work. I recognise this is new
> > and work in progress. However, I’m starting to see discussions
> > regarding the looks of future networks under the general ‘5G’ tag in
> > most SDOs and there is a lot of talk of virtualising everything to the
> > radio access network. I think that SFC should, at the very least, be
> considered as part of the control plane.
>
> Let's first see if we can get some discussion on this draft on the list.
> If there is interest, we can consider a slot at the next IETF meeting.
>
> Thomas & Jim
>
> >
> > Thanks, /PA
> >
> > PS: my excuses for possible multi-posting. I’m experiencing a lot of
> > problems with my email recetly --- Dr. Pedro A. Aranda Gutiérrez
> >
> > Technology Exploration - Network Innovation & Virtualisation email:
> > pedroa d0t aranda At telefonica d0t com Telefónica, Investigación y
> > Desarrollo C/
> > Zurbarán,12 28010 Madrid, Spain
> >
> > Fragen sind nicht da, um beantwortet zu werden.  Fragen sind da, um
> > gestellt zu werden.  Georg Kreisler
> >
> >
> >
> >
> > >
> > >-----Mensaje original----- De: "[e-mail]" Fecha:
> > >lunes, 5 de octubre de 2015, 7:53 Para: Walter Haeffner, DIEGO LOPEZ
> > >GARCIA, paag, DIEGO LOPEZ GARCIA, Walter Haeffner, paag Asunto: New
> > >Version Notification for draft-aranda-sf-dp-mobile-00.txt
> > >
> > >>
> > >>A new version of I-D, draft-aranda-sf-dp-mobile-00.txt has been
> > >>successfully submitted by Pedro A. Aranda and posted to the IETF
> repository.
> > >>
> > >>Name: draft-aranda-sf-dp-mobile Revision: 00 Title: Service Function
> > >>Chaining Dataplane Elements in Mobile Networks Document date:
> > >>2015-10-05
> > >>Group: Individual Submission Pages: 11 URL:
> > >>https://www.ietf.org/internet-drafts/draft-aranda-sf-dp-mobile-00.tx
> > >>t
> > >>Status: https://datatracker.ietf.org/doc/draft-aranda-sf-dp-mobile/
> > >>Htmlized: https://tools.ietf.org/html/draft-aranda-sf-dp-mobile-00
> > >>
> > >>
> > >>Abstract:
> > >>   The evolution of the network towards 5G implies a challenge for the
> > >>   infrastructure. The targeted services and the full deployment of
> > >>   virtualization in all segments of the network will need service
> function
> > >>   chains that previously resided in the(local and remote)
> infrastructure of
> > >>   the Network operators to extend to the radio access network (RAN).
> > >>
> > >>   The objective of this draft is to provide a non-exhaustive but
> > >>   representative list of service functions in 4G and 5G networks. We
> base
> > >>   on the problem statement [RFC 7498] and architecture framework
> [SFC-Arch]
> > >>   of the working group, as well on the existing mobile networks use
> cases
> > >>   [SFC-mobile-uc] and the requirement gathering process of different
> > >>   initiatives around the world [5GPPP, IMT2020, 5G-FK, IMT2020-CN ] to
> > >>   anticipate network elements that will be needed in 5G networks.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>Please note that it may take a couple of minutes from the time of
> > >>submission until the htmlized version and diff are available at
> tools.ietf.org.
> > >>
> > >>The IETF Secretariat
> > >>
> >
> > ________________________________
> >
> > Este mensaje y sus adjuntos se dirigen exclusivamente a su
> > destinatario, puede contener información privilegiada o confidencial y
> > es para uso exclusivo de la persona o entidad de destino. Si no es
> > usted. el destinatario indicado, queda notificado de que la lectura,
> > utilización, divulgación y/o copia sin autorización puede estar
> > prohibida en virtud de la legislación vigente. Si ha recibido este
> > mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
> >
> > The information contained in this transmission is privileged and
> > confidential information intended only for the use of the individual
> > or entity named above. If the reader of this message is not the
> > intended recipient, you are hereby notified that any dissemination,
> > distribution or copying of this communication is strictly prohibited.
> > If you have received this transmission in error, do not read it.
> > Please immediately reply to the sender that you have received this
> communication in error and then delete it.
> >
> > Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> > destinatário, pode conter informação privilegiada ou confidencial e é
> > para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> > senhoria o destinatário indicado, fica notificado de que a leitura,
> > utilização, divulgação e/ou cópia sem autorização pode estar proibida
> > em virtude da legislação vigente. Se recebeu esta mensagem por erro,
> > rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> > proceda a sua destruição
> > _______________________________________________ sfc mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/sfc
> >
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
>