Re: [DMM] Is IPv6 UDP checksum deployment impact an input to 3GPP?

[Behcet Sarikaya]

Hi Satoru,

I read your mail and have a few points to raise (BTW, all friendly, you and
I know each other since long time, and no offence).



On Thu, Oct 19, 2023 at 4:56 AM Satoru Matsushima <
satoru.matsush...@gmail.com> wrote:

> Dear DMMers,
>
> During IETF117 DMM meeting, we had a report of the IPv6 UDP checksum
> deployment impact in the following I-D:
>
>
> https://datatracker.ietf.org/doc/draft-murakami-dmm-udp-checksum-impact-gtpu/
>
> In the meeting room, the chairs observed that DMMers were interested in
> this draft as an input to 3GPP.
>
> Please let us know any of your feedback, comments on this draft, and to be
> an input to 3GPP.
>
>
Anybody can take a contribution to 3GPP as input if you belong to a member
company.

I know that Softbank is a member.


Another point, since you are a co-author, it would be better to let this
draft be handled by a co-chair.

Behcet

> Regards,
> -satoru
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document - Objections

[Behcet Sarikaya]

This is an excellent review.
More below.

On Tue, Jan 5, 2021 at 6:11 PM Joel M. Halpern  wrote:

> Looking agin at the document, I have multiple problems with adoption of
> this document.
>
> First, as just discussed, it seems to be laying out an archtiecture, but
> that architecture is not consistent with the other work going on in the
> IETF (specifically in the routing area, and known to many of the
> co-authors of this work.)
>
> Second, the document states that it is Informational, and then is
> written as if it is defining the one and only way to structure the
> needed system.
>
> Third, related to the second, this document seems to assert that there
> is a specific and correct way to use IETF technology to solve the
> problem.  Then, about three quarters of the way through it remembers
> that there are multiple alternatives for some parts.  The IETF rarely
> writes implementation specifications.  There are other SDOs that do so.
>

This reminds me what is happening in quic WG which keeps producing
implementation specs.



>   They can wrestle with the problem of defining something that can be
> utilized by multiple operators with varying constraints.  Why would we
> want to get into trying to have that fight?
>
> For the WG chairs, I am trying to figure out how this even fits the DMM
> charter.  It is a LOT more than network exposure, which is the closest I
> can see in the charter.
>
>
I had raised this charter issue long time before.
I pointed out that dmm has to recharter and even maybe make a BOF before
working on these.
They have all been ignored.

Hope that they won't this time :)

Folks, +1 on all counts.

I have to clarify that this mail is nothing personal, I know some authors,
they are my friends, the chairs are my friends.
No offense to anyone.

Happy New Year!

Behcet

> Yours, unhappily,
> Joel
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF106 - Call for Agenda Items

[Behcet Sarikaya]

Happy New Year everyone!

Thanks for this information Hannu.

Regards,
Behcet

On Thu, Jan 2, 2020 at 6:04 AM Flinck, Hannu (Nokia - FI/Espoo) <
hannu.fli...@nokia-bell-labs.com> wrote:

> Hello Miya and other authors of the draft
> https://www.ietf.org/id/draft-kohno-dmm-srv6mob-arch-00.txt
>
>
>
> Your draft notes that  SRv6 mobile user plane has been proposed as an
> alternative way to complement or replace GTP-U both in IETF
> [I-D.ietf-dmm-srv6-mobile-uplane] and 3GPP [TR.29892]. All the aspects
> (pros and cons) replacing GTP have already been assessed in details in the
> TR you are quoting. And in the conclusion section of the very same TR
> states that:
>
>
>
> “A technical vote took place during CT4#93 (26-30 August 2019) with the
> following question and results:
>
> Question: Do you want to standardize SRv6 user plane protocol (w/o GTP-U)
> as described in clause 6.2.2 of TR 29.892?
>
> Results:
> YES:   13.924 %
> NO: 86.076 %
> The quorum was reached.
>
> It was therefore concluded to not standardize the SRv6 user plane protocol
> (without GTP-U) solution within the scope of this study (i.e. based on
> stage 2 requirements specified in Rel-16).”
>
>
>
> I think it would be worth of mentioning in this draft as well.
>
>
>
> Best regards
>
> Hannu
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* dmm  *On Behalf Of *Miya Kohno
> *Sent:* Friday, November 1, 2019 7:39 PM
> *To:* Satoru Matsushima 
> *Cc:* fc...@cisco.com; dmm 
> *Subject:* Re: [DMM] IETF106 - Call for Agenda Items
>
>
>
> Dear DMM chairs,
>
>
>
> I would like to request a slot to discuss about the following draft.
>
>
>
> ---
>
> The title of the presentation: Architecture Discussion on SRv6 Mobile User
> plane
> Presenter name: Miya Kohno
> Time you need: 15min
> Draft reference:
> https://www.ietf.org/id/draft-kohno-dmm-srv6mob-arch-00.txt
>
> ---
>
>
>
> Thanks!
>
> Miya
>
>
>
> On Wed, Oct 23, 2019 at 11:49 AM Satoru Matsushima <
> satoru.matsush...@gmail.com> wrote:
>
> One correction for a typo:
>
> > Reminder:
> > The draft cut-off date: 4th November UTC 23:59 (2 weeks before the
> meeting).
>
>
> Regards,
> --satoru
>
>
> > 2019/10/22 12:07、Satoru Matsushima のメール:
> >
> > Folks,
> >
> > The DMM chairs are planning the dmm meeting in Singapore at IETF106:
> >
> > 18th November, Monday Afternoon Session II (15:50-17:50)
> >
> > If you have a draft or any topics you would like to discuss, please send
> your request for agenda time to the dmm chairs. Please include the
> information in the request as following:
> >
> > The title of the presentation:
> > Presenter name:
> > Time you need:
> > Draft reference:
> >
> > Please have agenda items to us by 2019-11-04 (November 4th).
> >
> > Reminder:
> > The draft cut-off date: 14th November UTC 23:59 (2 weeks before the
> meeting).
> >
> > Dapeng & Sri & Satoru
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] BGP-based DMM for civil aviation

[Behcet Sarikaya]

Hi Erik,

Happy New Year to all!

Unrelated to your question below, I noticed an error in one of the pages of
loon.co:

https://loon.co/technology/

I think that commercial airplanes fly a bit above 10 km or mostly around
10km orbit while the above page shows way below 10km.

Regards,
Behcet

On Mon, Jan 7, 2019 at 4:26 PM Erik Kline  wrote:

> Fred,
>
> Happy New Year.
>
> I'm not currently tracking rtgwg, so perhaps this is already addressed in
> discussion of there.  (And perhaps I should move dmm@ to bcc...)
>
> How does a MNP-bearing node (client) locate candidate s-ASBRs (similarly
> how does it locate a proxy)? And does the client try to form an eBGP
> session with the s-ASBR or use something else?
>
> I was also not clear on where administrative boundaries are in the various
> diagrams (though I assumed at least that c-ASBRs are within the MSP-owners
> administrative domain).
>
> Thanks,
> -Erik
>
> On Wed, 2 Jan 2019 at 12:37, Templin (US), Fred L <
> fred.l.temp...@boeing.com> wrote:
>
>> Hello, and Happy New Year,
>>
>> We have articulated what is essentially a Distributed Mobility Management
>> (DMM)
>> service for the next-generation civil aviation Aeronautical
>> Telecommunications
>> Network with Internet Protocol Services (ATN/IPS):
>>
>> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/
>>
>> This work tracks the progress of the International Civil Aviation
>> Organization
>> (ICAO), and is a working group item of the IETF RTGWG.
>>
>> The way it works is that there is a hub-and-spokes BGP overlay routing
>> service
>> that interconnects potentially many mobility anchor points. Each anchor
>> point is
>> responsible for mobility management for a constituent set of mobile nodes
>> (e.g., aircraft), such that the system as a whole supports large-scale
>> DMM.
>>
>> We think this document is in the correct home in RTGWG, but I just thought
>> I would start out the year by sensitizing the DMM community. Any thoughts
>> or comments are welcome.
>>
>> Thanks - Fred
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] draft-hmm-dmm-5g-uplane-analysis

[Behcet Sarikaya]

Hi all,
>From the link Dave Allan provided, here I copy the content of CT4 liaison.
There is a claim that this draft is not for 3GPP but for IETF. However if
you read the liaison, it was originally submitted to CT4.
I think this liaison is show stopper, again sorry to say that.

Here is the liaison:
CT4 reviewed the IETF draft-hmm-dmm-5g-uplane-analysis-00 based on the input
discussion paper submitted to CT4 in C4-185292. CT4 thanks IETF DMM for
their
analysis. CT4 would like to provide the following initial feedback on the
same.
CT4 intends to do further analysis and provide any additional feedback, if
any,
in future. CT4 would like to emphasize that the evaluation criteria for the
user plane protocol study (FS_UPPS) in 5GC shall be defined by 3GPP CT4 and
the
work has just now started in 3GPP.


Regards,
Behcet
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

[Behcet Sarikaya]

On Wed, Nov 14, 2018 at 3:53 PM David Allan I 
wrote:

> HI
>
>
>
> AFAIK 3GPP CT4 is looking for work it can adopt, and has indicated that it
> wishes to perform the analysis itself. When they were directed to this
> document in the recent IETF DMM liaison, it  resulted in a liaison reply
> clearly indicated they would define their own criteria.
>
> https://datatracker.ietf.org/liaison/1590/
>
>
>
> However in the draft it states in the introduction: “However we believe
> that to provide adequate information for 3GPP, we need to clearly
> understand what the current user plane protocol is in Release 15, and
> architectural requirements for the user plane.” And in the conclusion “Our
> conclusion here is that we suggest the UP protocol study work in 3GPP takes
> into account the evaluation aspects described in Section 5.”, there is
> more, but I do not feel a need to be pedantic about it.
>
>
>
> So the purpose of this draft seems to explicitly be to do work for 3GPP
> that they have explicitly said they DO NOT WANT.
>
>
>
> At the same time I do not see anything in the charter that suggests we
> should be doing this work either.  It would appear to have little to do
> with DMM’s chartered direction.
>
>
>
> As such I am opposed to adoption of the draft.
>
>
>

+1

I had raised similar issues before.

BTW no offense to Shunsuke.

and no offense to my friend Sri :-)

Behcet

> Cheers
>
> Dave
>
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Behcet Sarikaya]

Alex, user plane means data plane in 3GPP terminology.
Data plane versus control plane  separation to my knowledge has first been
introduced by 3GPP.

Behcet
PS. Maybe Sridhar can add some 3GPP standard quotes/references here.



On Fri, Oct 5, 2018 at 12:25 AM Alexandre Petrescu <
alexandre.petre...@gmail.com> wrote:

> Thank you very much for the clarification.
>
> I understand now that GTP is a user-plane function run in the network.
>
> - the UE (smartphone) never runs GTP.  I think this is worth putting in
>the draft and state it as such, if we so believe.
>
> - it is strange for me to call it a User-Plane Function while the user
>has no impact on it.  I think this abbreviation deserves
>clarification.  We can suggest to 3GPP to change the name.
>
> (terms like data-plane/control-plane (not user-plane) are already in
> widespread use, and could be improved).
>
> Alex
>
>
>
> Le 03/10/2018 à 18:29, Sridhar Bhaskaran a écrit :
> >  >>A UPF is any function that can be executed on user traffic in mobile
> > network. Having said that however, I think the first UPFs that we will
> > see will be in the form of SGW, PGW.
> >
> > Even this is not accurate..
> >
> > A UPF is a _*5G system core network*_ entity whereas the SGW-U and PGW-U
> > are EPC core network entities. 5G core network has many differences from
> > EPC. To avoid confusion it should be noted that 5G NR radio can be
> > deployed with EPC as the core network and technically such deployments
> > can also be called as 5G deployments. But an UPF has no role in such
> > deployments.
> >
> > Some of the user plane functionalities of an UPF are completely
> > different from SGW-U or PGW-U.. Here are few differences (not exhaustive)
> >
> > 1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any
> > QFI marking. UPF on the other hand has one GTP-U tunnel per PDU session..
> > Different QoS flows within that PDU session are identified based on the
> > QFI marking. So a UPF has to support QFI marking.
> > 2. An UPF can support classification and encapsulation Ethernet frames
> > whereas a SGW-U/PGW-U has no requirement to support classification and
> > encapsulation of Ethernet frames.
> > 3. An UPF supporting Ethernet PDU session type may support ARP proxying
> > / IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement..
> > 4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW-U has no
> > such requirement.
> >
> > One may say that SGW-U / PGW-U also plays a role in user plane
> > forwarding and hence why not call it a UPF?  For the lack of a better
> > terminology, 3GPP has called the entity that performs the user plane
> > functionalities and features within a _*5G core network*_ as UPF. Those
> > functionalities are not exactly similar to EPC.
> >
> > Thanks
> > Sridhar
> >
> > On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain
> > mailto:arashmid.akhav...@huawei.com>>
> wrote:
> >
> > Not necessarily,
> >
> > __ __
> >
> > You are correct in that PGW is a UPF, but a UPF is by no means
> > limited to PGW. A UPF is any function that can be executed on user
> > traffic in mobile network. Having said that however, I think the
> > first UPFs that we will see will be in the form of SGW, PGW.
> >
> > __ __
> >
> > Arashmid
> >
> > __ __
> >
> > *From:*dmm [mailto:dmm-boun...@ietf.org
> > <mailto:dmm-boun...@ietf.org>] *On Behalf Of *Behcet Sarikaya
> > *Sent:* Tuesday, October 02, 2018 11:44 AM
> > *To:* Shunsuke Homma  > <mailto:homma.shuns...@lab.ntt.co.jp>>
> > *Cc:* dmm mailto:dmm@ietf.org>>
> > *Subject:* Re: [DMM] Comments to
> draft-hmm-dmm-5g-uplane-analysis-01
> >
> > __ __
> >
> > UPF is virtualized PGW, folks.
> >
> > While PGW is fixed in location and possibly serving a large number
> > of UE which are geographically in the area, that part of the city
> > and that city itself, UPF can be deployed closer to the UE and thus
> > probably serving smaller number of UEs
> >
> > __ __
> >
> > Behcet
> >
> > __ __
> >
> > On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma
> > mailto:homma.shuns...@lab.ntt.co.jp>>
> > wrote:
> >
> > Thanks Dark for your explaining what is UPF instead of me.
> >
> > Alex, brief definitions of UPF are described 

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Behcet Sarikaya]

UPF is virtualized PGW, folks.
While PGW is fixed in location and possibly serving a large number of UE
which are geographically in the area, that part of the city and that city
itself, UPF can be deployed closer to the UE and thus probably serving
smaller number of UEs

Behcet

On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma 
wrote:

> Thanks Dark for your explaining what is UPF instead of me.
>
> Alex, brief definitions of UPF are described in the section 4.1.1.1 of
> this draft. Also, you can find more details in 3GPP TS23.501.
>
> Regards,
>
> Shunsuke
>
> On 2018/10/01 20:32, dirk.von-h...@telekom.de wrote:
> > Hi Alex,
> > and sorry for jumping into the discussion...
> >  From my and (AFAIK) 3GPPs understanding your smartphone is a UE -
> sitting on the other side of RAN (gNB) - whereas a UPF normally is seen as
> UP entry (and exit) of the 5G core (i.e. handling all UP traffic in a true
> CP/UP split fashion).
> > Any other ideas on this? Can someone imagine any scenario where UE
> implements UPF?
> > Thanks!
> > Best Regards
> > Dirk
> >
> > -Original Message-
> > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandre Petrescu
> > Sent: Montag, 1. Oktober 2018 13:22
> > To: dmm@ietf.org
> > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> >
> >
> >
> > Le 01/10/2018 à 05:50, Shunsuke Homma a écrit :
> >> Hi all,
> >> # Sorry for my late response...
> >>
> >> Thank you for your lively discussion. It is very helpful for
> >> understanding points which need supplemental explanation and more
> >> consideration.
> >>
> >> Following the discussion, we're planning to update the I-D for
> >> covering the points below:
> >>
> >> - termination points of GTP-U
> >> (RANs and UPFs terminate GTP-U in 5GS.)
> >
> > What is UPF?
> >
> > I understand UPF stands for User-Plane Function.
> >
> > Is my smartphone supposed to implement UPF?
> >
> > Alex
> >
> >> - setting QoS parameter of outer IP header
> >> (Note that it's not just copy of inner to outer.)
> >> - problems related to IP connectivity (e.g., MTU in IPv6 networks,
> >> IPv4 address duplication)
> >> - summary of network slicing in 5GS
> >> (E.g., "slice is composed of SMF and UPFs. AMF selects SMF
> >> depending on NSSAI sent from UE, and SMF indicates to the UE the UPF
> >> that it is
> >> allocated.")
> >> - case studies on UPF selection
> >> (E.g., parameters used for deciding destination UPF) # Optimizing
> >> forwarding paths solution might be realized with UPF selection
> >> mechanism in 3GPP architecture. (ID-LOC may be applied as such
> >> mechanism.)
> >>
> >>
> >> If you have any request for us on this updating, please let us know.
> >>
> >> Best regards,
> >>
> >> Shunsuke
> >>
> >> On 2018/09/08 3:28, Dino Farinacci wrote:
>  I understand your point, but there is no guarantee for a precise QoS
>  without using some sort of encapsulation being it GTP, RSVP, etc.
>  Even with tunnels, there is no guarantee that all nodes along the
>  path have the same hardware capability and can provide the same QoS
>  treatment.
> >>>
> >>> There is existing hardware where the encapsulator copies inner QoS to
> >>> outer QoS. All routers along the path just process the outer QoS, no
> >>> changes to or new processing requirements for them.
> >>>
>  For example, the code points in routers need to be configured to
>  correctly handle the EXP bits in MPLS labels. But there is no
>  guarantee that all routers can support all values. The EXP values
>  get mapped to code points but the mapping is not always one to one.
>  3-bit EXPs can map to 4 code points on those routers with less
>  capable H/W.
> >>>
> >>> That is a completely different matter. The discussion is about
> >>> remarking. And if one remarks to what the path cannot support, well
> >>> things don’t work as expected.
> >>>
>  Slicing is almost the same. It allows user traffic to be mapped to
>  what the operator provides.
>  I agree with you that network should not touch/change original
>  header bits. GTP or any other encapsulation easily allow for this.
>  The question is whether we can provide for this without using
>  encapsulation. IPv6 might be the answer. But as Tom pointed out,
>  flow labels can still change in the middle. Is there any room for
>  improvement. SIDs might present an opportunity.
> >>>
> >>> Not if they are encapsulated and routers don’t touch packets inside.
> >>>
> >>> Dino
> >>>
> 
> 
> 
> 
> 
> > -Original Message-
> > From: Dino Farinacci [mailto:farina...@gmail.com]
> > Sent: 07 September 2018 13:08
> > To: Arashmid Akhavain 
> > Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
> > dmm 
> > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> >
> > I think you’ll still have the PHB re-marking issues I mentioned in
> > previous emails. The question is, should the 

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Behcet Sarikaya]

Folks, let's not forget that most of these things you are talking about are
session layer issues.
According to OSI layering, the session layer is Layer 5, above Layer 4
which is transport layer.
3GPP is using UDP which is Layer 4 for this session layer coding. I think
probably it is a better layer than the Internet layer which would be the
case with IdLoc protocols, I think even with LISP which uses UDP
encapsulation.

Behcet

On Thu, Sep 6, 2018 at 11:21 AM Tom Herbert  wrote:

> On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya 
> wrote:
> >
> >
> > On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:
> >>
> >> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
> >>  wrote:
> >> > My comments inline marked [SB]
> >> >
> >> >> > >>> It was never clear to me and no one could ever explain exactly
> >> >> > >>> why a
> >> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
> >> >> > >>> was a
> >> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
> >> >> > >>> inner addresses
> >> >> > >>> be used for accounting?
> >> >> >
> >> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
> >> >> > tunnel and hence consequently a bearer. Once the bearer context is
> >> >> > identified the QoS and charging policy applicable to the bearer is
> >> >> > applied.
> >> >> > So the purpose of TEID is not just for accounting. Its for QoS
> >> >> > treatment,
> >> >> > charging and bearer context identification.
> >> >>
> >> >> You told me what a TEID is but you didn’t say why you need to use it
> >> >> versus using the destination IP address for the tunnel.
> >> >>
> >> >>
> >> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the
> PDU
> >> >> > session whereas the QFI carried in GTPU extension header identifies
> >> >> > the
> >> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
> >> >>
> >> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
> >> >> which
> >> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
> >> >> encapsualting node, and (4) the decapsulating node.
> >> >>
> >> >> So again, why use more space in the packet, when you have sufficient
> >> >> information to identify a user, and therefore their packet policy?
> >> >>
> >> > [SB] Lets say we only use UE IP address and no TEID. How will you
> >> > identify
> >> > the bearer context the packet belongs? One UE may use multiple radio
> >> > bearers
> >> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but
> these
> >> > are
> >> > IP level markings which could be changed by any on path routers. In
> >> > order to
> >> > uniquely identify the bearer / qos flow a particular packet for a UE
> >> > belongs, GTPU uses TEID.
> >>
> >> Sridhar,
> >>
> >> Couldn't the TEID be encoded in the outer IP address of an
> >> encpasulation or network overlay in a similar way that VNIs are
> >> encoded in IP addresses in virtual networking?
> >>
> >> Tom
> >>
> >
> > ILA if used would remove any need for tunneling and TEID is for
> tunneling.
> >
> Behcet,
>
> I was thinking if TEID is need then that can be encoded in a locator
> easily enough.
>
> Tom
>
> > Actually if you read 29.244 it is completely based on legacy protocols
> with
> > no IdLoc content at all, as Shunsuke mentioned.
> >
> > Behcet
> >>
> >> >
> >> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
> >> > are
> >> > not always unique. The same IP pools can be shared across multiple
> PDNs
> >> > /
> >> > DNs as long as these PDNs / DNs are separate autonomous networks. So
> >> > just
> >> > relying on UE IP address alone will result in wrong context
> >> > identification
> >> > for the uplink traffic. There is a clear one to one mapping of Radio
> >> > bearer
> >> > to the EPS bearer / QoS flow required all the way upto the anchor node
&g

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Behcet Sarikaya]

Hi Marco,

On Thu, Sep 6, 2018 at 11:39 AM Marco Liebsch 
wrote:

> Tom, Behcet, I think TEID may still be needed in some cases, e.g. for
> mapping to a radio bearer
> or to avoid superfluous packet classification if it has been done on the
> packet's path beforehand
> already.
>
>
 So it should be treat as a special case.
My suggestion is let's solve the main problem first, i.e. privacy issues,
make idloc deployable in large scale.

IMO, for non-encapsulation protocols, overloading of id-loc space seems
> interesting if the attribute
> cannot be carried in extensions. What about encoding QoS class/flow IDs in
> that space as well ;-) ?
>
>
Sure.


Behcet

> marco
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: Donnerstag, 6. September 2018 18:22
> To: Behcet Sarikaya
> Cc: ta-miyas...@kddi-research.jp; dmm
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>
> On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya 
> wrote:
> >
> >
> > On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:
> >>
> >> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
> >>  wrote:
> >> > My comments inline marked [SB]
> >> >
> >> >> > >>> It was never clear to me and no one could ever explain exactly
> >> >> > >>> why a
> >> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
> >> >> > >>> was a
> >> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
> >> >> > >>> inner addresses
> >> >> > >>> be used for accounting?
> >> >> >
> >> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
> >> >> > tunnel and hence consequently a bearer. Once the bearer context is
> >> >> > identified the QoS and charging policy applicable to the bearer is
> >> >> > applied.
> >> >> > So the purpose of TEID is not just for accounting. Its for QoS
> >> >> > treatment,
> >> >> > charging and bearer context identification.
> >> >>
> >> >> You told me what a TEID is but you didn’t say why you need to use it
> >> >> versus using the destination IP address for the tunnel.
> >> >>
> >> >>
> >> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the
> PDU
> >> >> > session whereas the QFI carried in GTPU extension header identifies
> >> >> > the
> >> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
> >> >>
> >> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
> >> >> which
> >> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
> >> >> encapsualting node, and (4) the decapsulating node.
> >> >>
> >> >> So again, why use more space in the packet, when you have sufficient
> >> >> information to identify a user, and therefore their packet policy?
> >> >>
> >> > [SB] Lets say we only use UE IP address and no TEID. How will you
> >> > identify
> >> > the bearer context the packet belongs? One UE may use multiple radio
> >> > bearers
> >> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but
> these
> >> > are
> >> > IP level markings which could be changed by any on path routers. In
> >> > order to
> >> > uniquely identify the bearer / qos flow a particular packet for a UE
> >> > belongs, GTPU uses TEID.
> >>
> >> Sridhar,
> >>
> >> Couldn't the TEID be encoded in the outer IP address of an
> >> encpasulation or network overlay in a similar way that VNIs are
> >> encoded in IP addresses in virtual networking?
> >>
> >> Tom
> >>
> >
> > ILA if used would remove any need for tunneling and TEID is for
> tunneling.
> >
> Behcet,
>
> I was thinking if TEID is need then that can be encoded in a locator
> easily enough.
>
> Tom
>
> > Actually if you read 29.244 it is completely based on legacy protocols
> with
> > no IdLoc content at all, as Shunsuke mentioned.
> >
> > Behcet
> >>
> >> >
> >> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
> >> > are
> >> > 

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Behcet Sarikaya]

On Fri, Sep 7, 2018 at 8:35 AM Alexandre Petrescu <
alexandre.petre...@gmail.com> wrote:

>
>
> Le 06/09/2018 à 12:27, Sridhar Bhaskaran a écrit :
> > Dear Behcet,
> >
> >  >>What is PFCP, is it GTP-U?
> >
> > PFCP is a control plane protocol used between control plane function and
> > user plane function. In EPC, the PFCP protocol is used on the Sx
> > interface. In 5G its used on the N4 interface. It is used to set up the
> > packet classifiers and forwarding rules in the user plane function.
>
> It's the first time I hear about this.
>
> Where was discussed the allocation of this port number?
>
>
Individuals can ask IANA to assign port numbers for their applications, I
think. In this case Kimmo asked in the name of 3GPP CT4
in 2017 as the recording shows.
I don't think there is any associated draft as PFCP which is a UDP
application was defined by CT4 much like GTP-U.
If you remember Cameron used to say that are a lot of protocols used in
practice defined elsewhere not in IETF.

Behcet

> Alex
>
> >
> > Thanks
> > Sridhar
> >
> >
> > ___
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
> >
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Behcet Sarikaya]

On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:

> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
>  wrote:
> > My comments inline marked [SB]
> >
> >> > >>> It was never clear to me and no one could ever explain exactly
> why a
> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
> was a
> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
> inner addresses
> >> > >>> be used for accounting?
> >> >
> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
> >> > tunnel and hence consequently a bearer. Once the bearer context is
> >> > identified the QoS and charging policy applicable to the bearer is
> applied.
> >> > So the purpose of TEID is not just for accounting. Its for QoS
> treatment,
> >> > charging and bearer context identification.
> >>
> >> You told me what a TEID is but you didn’t say why you need to use it
> >> versus using the destination IP address for the tunnel.
> >>
> >>
> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
> >> > session whereas the QFI carried in GTPU extension header identifies
> the
> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
> >>
> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
> which
> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
> >> encapsualting node, and (4) the decapsulating node.
> >>
> >> So again, why use more space in the packet, when you have sufficient
> >> information to identify a user, and therefore their packet policy?
> >>
> > [SB] Lets say we only use UE IP address and no TEID. How will you
> identify
> > the bearer context the packet belongs? One UE may use multiple radio
> bearers
> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these
> are
> > IP level markings which could be changed by any on path routers. In
> order to
> > uniquely identify the bearer / qos flow a particular packet for a UE
> > belongs, GTPU uses TEID.
>
> Sridhar,
>
> Couldn't the TEID be encoded in the outer IP address of an
> encpasulation or network overlay in a similar way that VNIs are
> encoded in IP addresses in virtual networking?
>
> Tom
>
>
ILA if used would remove any need for tunneling and TEID is for tunneling.

Actually if you read 29.244 it is completely based on legacy protocols with
no IdLoc content at all, as Shunsuke mentioned.

Behcet

> >
> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
> are
> > not always unique. The same IP pools can be shared across multiple PDNs /
> > DNs as long as these PDNs / DNs are separate autonomous networks. So just
> > relying on UE IP address alone will result in wrong context
> identification
> > for the uplink traffic. There is a clear one to one mapping of Radio
> bearer
> > to the EPS bearer / QoS flow required all the way upto the anchor node
> for
> > charging and QoS treatment. This comes from the requirements in stage 2
> > documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
> > 5G).
> >
> > There are also requirements to support non-IP protocols like Ethernet PDU
> > and Unstructured PDU types in 5G.
> >
> >> >>
> >> > >>> How can packets be sent if the session is not setup. If the
> session
> >> > >>> is not setup, the encapsulator should have no state. And packets
> should be
> >> > >>> dropped locally and not go far to get an error back. This sounds
> >> > >>> architecturally broken.
> >> >
> >> > [Sridhar] The purpose of GTP-U error indication is to signal in band
> to
> >> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side
> is lost
> >> > for any reason. "No session exist" does not mean Session
> >>
> >> What does lost mean? You mean the path from encapsulator to decapsulator
> >> is not working? And since we are in a packet network, that path can be
> >> restored quite quickly.
> >
> >
> > [SB] Lost here means - the "context" at the receiving entity is deleted..
> For
> > e.g due to administrative reasons, gNB or eNB removes the radio bearers
> and
> > correspondingly the GTPU context. If gNB or eNB loses a context for known
> > reasons, there could be signaling from gNB / eNB to AMF/MME and
> > corresponding removal of PDU session / EPS bearer at the core network.
> But
> > if the context is removed due to administrative reasons or unforeseen
> local
> > errors, signaling from gNB / eNB to AMF / MME may not happen. Hence the
> GTPU
> > error indication is an inband error detection mechanism.
> >
> > Note TEID identifies a context at the receiving side. So all GTPU error
> > indication tells is that the receiver is not able to identify any context
> > for the received TEID.
> >
> >>
> >> > is not setup. "No session exist" scenario after a session setup can
> >> > happen due to local error conditions, bearers released for
> administrative
> >> > reasons etc.
> >>
> >> So at the encapsulator, do you choose another decapsultor? Note that
> >> tunnels 

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Behcet Sarikaya]

On Wed, Sep 5, 2018 at 3:56 AM Sridhar Bhaskaran <
sridhar.bhaska...@gmail.com> wrote:

> Dear Dino,
>
> Some clarifications on your comments
>
> >>> It was never clear to me and no one could ever explain exactly why a
> TEID is needed. I presumed for accounting reasons. But if there was a
> one-to-one mapping between tunnel and user, why couldn’t the inner
> addresses be used for accounting?
>
> [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a tunnel
> and hence consequently a bearer. Once the bearer context is identified the
> QoS and charging policy applicable to the bearer is applied. So the purpose
> of TEID is not just for accounting. Its for QoS treatment, charging and
> bearer context identification.
>
> In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
> session whereas the QFI carried in GTPU extension header identifies the
> flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>
> >>> How can packets be sent if the session is not setup. If the session is
> not setup, the encapsulator should have no state. And packets should be
> dropped locally and not go far to get an error back. This sounds
> architecturally broken.
>
> [Sridhar] The purpose of GTP-U error indication is to signal in band to
> the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is
> lost for any reason. "No session exist" does not mean Session is not setup.
> "No session exist" scenario after a session setup can happen due to local
> error conditions, bearers released for administrative reasons etc.
>
> >>> You should explain in summary form the model the control-plane uses.
> Does it use TCP for reliability, does it use multicast, is it like a
> routing protocol, is it like a management protocol. What are the failure
> modes, the state/bandwidth tradeoffs.
>
> [Sridhar] Explaining all these in IETF draft is simply reproducing what is
> already there in TS 29.244. A reference to TS 29.244 should be enough. See
> section 6.4 of TS 29.244 for reliable delivery of PFCP messages.
>
>
I checked in IETF IANA UDP assignments,

pfcp 8805 udp Destination Port number for PFCP [Kimmo_Kymalainen

] [Kimmo_Kymalainen

] 2017-05-08
 for packet forwarding control protocol. What is PFCP, is it GTP-U?

Behcet

> Thanks
> Sridhar
> 3GPP CT4 Delegate
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] New Mailing List for draft-nordmark-id-loc-privacy-00.txt

[Behcet Sarikaya]

Hi all,

A new mailing list to discuss Privacy and Security issues with
Identifier/Locator (Id-Loc) separation protocols in the Internet
called
PIdLoc

has been created.

You can subscribe to the list at:

https://www.ietf.org/mailman/listinfo/pidloc

5gangip list will continue to host the discussions on 5G issues such as
deployment, operations and so on.

For all Id-Loc discussions including  the discussions on
draft-nordmark-id-loc-privacy, the new address is
pid...@ietf.org.

Many thanks to Security Area ADs, Eric Rescorla and Ben Kaduk for their
help and encouragements.
So we are in security area!

Regards,
Behcet also for Dirk
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

[Behcet Sarikaya]

On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) <
gcaro...@cisco.com> wrote:

> This draft is about hICN and discusses various deployment options with
> associated pros and cons, without supporting one specifically. Clearly,
> depending on  application requirements, on network constraints, on phase of
> deployment/transition  etc. one option may be preferrable over another one
> (and different ones may coexist).
>
>
> One of the described deployment options also discusses combination of hICN
> and SRv6, without opposing one approach to the other, rather exploiting in
> the combination the advantages of both ones.
>
>
>
I don't understand.
SRv6 is tunneling technique while hICN is talking about anchoress mobility.
Did I get something wrong?

Behcet

> Giovanna
> ------
> *From:* Int-area  on behalf of Behcet Sarikaya
> 
> *Sent:* Wednesday, June 20, 2018 4:18 PM
> *To:* Luca Muscariello
> *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm
> *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility
> management through hICN (hICN-AMM): Deployment options
>
>
>
> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello <
> luca.muscarie...@gmail.com> wrote:
>
>> I wonder whether this conversation should happen in the intarea wg
>> mailing list
>> as the main draft was posted there in the first place. I don't know if
>> cross posting is welcome
>> but I take the risk.
>>
>> Going back to the question, the transport changes are related to the
>> request/reply semantic
>> of the architecture. The two distinct forwarding paths described in the
>> draft take care
>> of forwarding requests or replies.This ends up in the transport layer as
>> a unidirectional
>> channel to recv data or snd data. The replies carry data originating from
>> a  transport end-point (snd buffer)
>> that binds to an identifier which is location independent, an IPv6 number
>> which is not a locator.
>>
>> The forwarding path of the requests is very close to unmodified IPv6 with
>> the DST address carrying the identifier.
>> If you check in the draft an hICN node does one additional lookup in a
>> local cache though. But you can ignore that
>> for now for sake of clarity. What is important is the address rewrite
>> operation made on the SRC address
>> of the request. A copy of the request is stored in the local cache and
>> the locator of the output interface is written in the
>> SRC address before transmission. This is used by an upstream hICN or the
>> final end-point to know the locator that
>> will be used to reply.
>>
>> Replies coming from the snd end-point are label swapped but not like
>> MPLS.
>> The label is the identifier itself that is stored in the SRC address of
>> the reply,
>> whereas the DST address is a locator. In this forwarding path a lookup is
>> made in the local cache to
>> find a request (one or many) and the associated locator (one or many)
>> that matches the identifier.
>> The DST addr field of the replies is rewritten with the locator(s) just
>> obtained from the lookup.
>> This is how the reply is forwarded to the end-points that issued requests
>> for this identifier.
>>
>> For the replies there is no FIB lookup on the identifier (as it is in the
>> SRC addr field).
>> There can be a lookup in the FIB on the locator stored in the DST of the
>> reply to
>> reach back the previous hICN node or eventually the original end-point.
>>
>>
>>
>>
>
> Hi,
>
> My humble question is: are you supporting SRv6 or hICN?
>
> Regards
> Behcet
>
>
>>
>>
>>
>>
>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert  wrote:
>>
>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
>>>  wrote:
>>> > The paragraph you reported is from the draft that describes hICN to
>>> enable
>>> > several use cases.
>>> > Mobility is one of those, not the only one.
>>> > To clarify, the draft on hICN mobility deployment options focuses on
>>> the 5G
>>> > service based architecture.
>>> >
>>> > You may be asking
>>> > 1) is it possible to get all the features provided by hICN w/o updates
>>> to
>>> > the transport layer?
>>> > 2) is changing the transport protocol unnecessary difficult to enable
>>> all
>>> > the use cases mentioned in the draft?
>>> >
>>> Sorry, but I'm still missing something fundamental here. AFAICT, the
>>

Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

[Behcet Sarikaya]

On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello <
luca.muscarie...@gmail.com> wrote:

> I wonder whether this conversation should happen in the intarea wg mailing
> list
> as the main draft was posted there in the first place. I don't know if
> cross posting is welcome
> but I take the risk.
>
> Going back to the question, the transport changes are related to the
> request/reply semantic
> of the architecture. The two distinct forwarding paths described in the
> draft take care
> of forwarding requests or replies.This ends up in the transport layer as a
> unidirectional
> channel to recv data or snd data. The replies carry data originating from
> a  transport end-point (snd buffer)
> that binds to an identifier which is location independent, an IPv6 number
> which is not a locator.
>
> The forwarding path of the requests is very close to unmodified IPv6 with
> the DST address carrying the identifier.
> If you check in the draft an hICN node does one additional lookup in a
> local cache though. But you can ignore that
> for now for sake of clarity. What is important is the address rewrite
> operation made on the SRC address
> of the request. A copy of the request is stored in the local cache and the
> locator of the output interface is written in the
> SRC address before transmission. This is used by an upstream hICN or the
> final end-point to know the locator that
> will be used to reply.
>
> Replies coming from the snd end-point are label swapped but not like MPLS.
> The label is the identifier itself that is stored in the SRC address of
> the reply,
> whereas the DST address is a locator. In this forwarding path a lookup is
> made in the local cache to
> find a request (one or many) and the associated locator (one or many) that
> matches the identifier.
> The DST addr field of the replies is rewritten with the locator(s) just
> obtained from the lookup.
> This is how the reply is forwarded to the end-points that issued requests
> for this identifier.
>
> For the replies there is no FIB lookup on the identifier (as it is in the
> SRC addr field).
> There can be a lookup in the FIB on the locator stored in the DST of the
> reply to
> reach back the previous hICN node or eventually the original end-point.
>
>
>
>

Hi,

My humble question is: are you supporting SRv6 or hICN?

Regards
Behcet


>
>
>
>
> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert  wrote:
>
>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
>>  wrote:
>> > The paragraph you reported is from the draft that describes hICN to
>> enable
>> > several use cases.
>> > Mobility is one of those, not the only one.
>> > To clarify, the draft on hICN mobility deployment options focuses on
>> the 5G
>> > service based architecture.
>> >
>> > You may be asking
>> > 1) is it possible to get all the features provided by hICN w/o updates
>> to
>> > the transport layer?
>> > 2) is changing the transport protocol unnecessary difficult to enable
>> all
>> > the use cases mentioned in the draft?
>> >
>> Sorry, but I'm still missing something fundamental here. AFAICT, the
>> idea of hICN is to put routes in the local routing table and use
>> existing forwarding and routing to forward packets to mobile nodes. So
>> if a node changes location, then the routing tables need to be
>> updated. Effectively this is a bunch of host routes that need to be
>> maintained. At least this is what I gather from the draft:
>>
>> "hICN network layer is about using the IPv6 FIB to determine a next
>> hop router to forward requests or using a local packet cache to
>> determine if an incoming request can be satisfied locally."
>>
>> Is this correct? If it is, then I sort of understand how hICN could be
>> used for mobility or virtualization without network overlays, but then
>> I'm completely lost as to why this would require any changes in the
>> transport layer.
>>
>> Tom
>>
>>
>>
>>
>>
>> > IMO, the answers are no for both.
>> >
>> > Luca
>> >
>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert  wrote:
>> >>
>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>> >>  wrote:
>> >> > Hi all,
>> >> >
>> >> > the draft below has been posted and describes deployments options for
>> >> > anchorless mobility management  by using
>> >> > the hicn network architecture that implements icn semantics in IPv6
>> >> > networks.
>> >> >
>> >> >
>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-
>> mobility-deployment-options
>> >> >
>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/
>> >> >
>> >> > A background document has been posted to the internet area WG and
>> >> > reported
>> >> > here for your convenience.
>> >> > The core principle behind hicn and mobility management is that data
>> >> > sources
>> >> > are named using location independent names
>> >> > encoded in IPv6 addresses. The transport service sitting on top of
>> the
>> >> > hicn
>> >> > architecture is not based on usual TCP/UDP sockets
>> >> > but on a novel consumer/producer transport 

[DMM] draft-ietf-dmm-pmipv6-dlif-00.txt

[Behcet Sarikaya]

Hi all,

I looked through this draft and my initial reaction is that I think that
this draft corresponds to what I called the dmm protocol in my mail a few
weeks ago.

I think it is a few years late, it should have been around already.
Nevertheless, I view it is a positive that now we have this work. I suggest
change the title to the dmm protocol
reduce the number of acronyms, some of them pretty confusing like CMD
finalize it as quickly as possible
call it quits.

Regards,
Behcet

On Thu, Apr 19, 2018 at 10:42 AM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the
> IETF.
>
> Title   : Proxy Mobile IPv6 extensions for Distributed
> Mobility Management
> Authors : Carlos J. Bernardos
>   Antonio de la Oliva
>   Fabio Giust
>   Juan Carlos Zuniga
>   Alain Mourad
> Filename: draft-ietf-dmm-pmipv6-dlif-00.txt
> Pages   : 32
> Date: 2018-04-18
>
> Abstract:
>Distributed Mobility Management solutions allow for setting up
>networks so that traffic is distributed in an optimal way and does
>not rely on centralized deployed anchors to provide IP mobility
>support.
>
>There are many different approaches to address Distributed Mobility
>Management, as for example extending network-based mobility protocols
>(like Proxy Mobile IPv6), or client-based mobility protocols (as
>Mobile IPv6), among others.  This document follows the former
>approach, and proposes a solution based on Proxy Mobile IPv6 in which
>mobility sessions are anchored at the last IP hop router (called
>mobility anchor and access router).  The mobility anchor and access
>router is an enhanced access router which is also able to operate as
>local mobility anchor or mobility access gateway, on a per prefix
>basis.  The document focuses on the required extensions to
>effectively support simultaneously anchoring several flows at
>different distributed gateways.
>
>This document introduces the concept of distributed logical
>interface, which is a software construct that allows to easily hide
>the change of anchor from the mobile node.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-pmipv6-dlif-00
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] 3GPP CT4 Study Item on the User Plane Protocols

[Behcet Sarikaya]

In my opinion the study should compare SRv6 solution which was why this
study item was created in the first place with the protocol(s) dmm group
developed which would be logical since the work is taking place in dmm?

I looked at dmm web site and in its 8 year history, there seems to be no
new "protocol" defined so far. However the main idea with dmm was to work
on distributing the mobility anchor which was HA or LMA in previous efforts.

I noticed that when you look into 5G architecture, 3GPP already adopted
this idea and developed a good solution based on GTP-U. In 4G there was a
fixed anchor called PGW and now in 5G there are distributed anchors called
UPFs. So here we do have a protocol which we can call dmm protocol.

IMHO, the study should compare SRv6 with GTP-U and that is probably going
to serve 3GPP purposes as well as other parties.

Regards,
Behcet

>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

[Behcet Sarikaya]

On Tue, Mar 20, 2018 at 11:47 AM, Sri Gundavelli (sgundave) <
sgund...@cisco.com> wrote:

> Not sure I agree Behcet. Generally, the distributed mobility management
> charter does cover optimizations in user-plane and control plane. But, for
> now, lets not discuss if this is in scope for this WG, or not. Lets focus
> on technical discussions.
>
>
I know it is procedural.
But it keeps coming up.
I was just reacting to your own mail,
you mentioned that all those drafts are individual.
I think it would help dmm people to see the full perspective.

Regards,
Behcet

> Sri
>
>
> From: Behcet Sarikaya <sarikaya2...@gmail.com>
> Reply-To: "sarik...@ieee.org" <sarik...@ieee.org>
> Date: Tuesday, March 20, 2018 at 3:43 AM
> To: Sri Gundavelli <sgund...@cisco.com>
> Cc: "Bogineni, Kalyani" <kalyani.bogin...@verizonwireless.com>, Lyle
> Bertz <lyleb551...@gmail.com>, dmm <dmm@ietf.org>
>
> Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-
> mobile-user-plane-00
>
>
>
> On Tue, Mar 20, 2018 at 11:28 AM, Sri Gundavelli (sgundave) <
> sgund...@cisco.com> wrote:
>
>> >  [KB] I will let Sri answer this.
>>
>> Nothing specific to MFA draft, but I will make a general comment.
>>
>>
>
>
>> If there is consensus to adopt draft-bogineni as a WG document, and if
>> this work becomes part of the WG charter, I would think the document should
>> include all IETF proposals under discussion for the given problem statement
>> on user-pane optimization.
>>
>
>
>> At this point, its an individual I-D and it is up to the authors on what
>> to include, or what to exclude.
>>
>>
> Right.
>
> I think that 3GPP Study Item related drafts (there is also  Homma draft,
> all ILA, LISP etc ID-Loc drafts and 5G work) are better
> stay as purpose specific individual drafts.
>
> Otherwise including them to dmm charter, a rechartering of such a scale I
> believe should require a BoF.
>
> My three cents :-)
>
> Regards,
> Behcet
>
>> Sri
>>
>>
>> From: dmm <dmm-boun...@ietf.org> on behalf of "Bogineni, Kalyani" <
>> kalyani.bogin...@verizonwireless.com>
>> Date: Tuesday, March 20, 2018 at 3:14 AM
>> To: Lyle Bertz <lyleb551...@gmail.com>, dmm <dmm@ietf.org>
>> Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-m
>> obile-user-plane-00
>>
>> Will MFA be proposed as an option
>> draft-gundavelli-dmm-mfa-00 [KB] I will let Sri answer this.
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

[Behcet Sarikaya]

On Tue, Mar 20, 2018 at 11:28 AM, Sri Gundavelli (sgundave) <
sgund...@cisco.com> wrote:

> >  [KB] I will let Sri answer this.
>
> Nothing specific to MFA draft, but I will make a general comment.
>
>


> If there is consensus to adopt draft-bogineni as a WG document, and if
> this work becomes part of the WG charter, I would think the document should
> include all IETF proposals under discussion for the given problem statement
> on user-pane optimization.
>


> At this point, its an individual I-D and it is up to the authors on what
> to include, or what to exclude.
>
>
Right.

I think that 3GPP Study Item related drafts (there is also  Homma draft,
all ILA, LISP etc ID-Loc drafts and 5G work) are better
stay as purpose specific individual drafts.

Otherwise including them to dmm charter, a rechartering of such a scale I
believe should require a BoF.

My three cents :-)

Regards,
Behcet

> Sri
>
>
> From: dmm  on behalf of "Bogineni, Kalyani" <
> kalyani.bogin...@verizonwireless.com>
> Date: Tuesday, March 20, 2018 at 3:14 AM
> To: Lyle Bertz , dmm 
> Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-m
> obile-user-plane-00
>
> Will MFA be proposed as an option
> draft-gundavelli-dmm-mfa-00 [KB] I will let Sri answer this.
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Mapping System scalability

[Behcet Sarikaya]

Hi Alberto,

It seems like you are not in 5G IP mailing list (cc'ed above 5gangip).
At 5gangip we decided to work on end to end privacy enabled mapping system
and the group has a side meeting as follows:

Thursday March 22nd, 10:00 - 11:30 Room: IETF Side Meetings room

We are going to take your mail as input from LISP side.

Regards,
Behcet

On Fri, Mar 16, 2018 at 3:19 AM, Alberto Rodriguez-Natal <
rodriguezna...@gmail.com> wrote:

> Hi all,
>
> In the DMM call this week, some people asked about the scalability of the
> Mapping System. The LISP community has delivered different solutions to
> address that challenge over the years. Here are some pointers to different
> Mapping System implementations, I'm sure that the folks at the LISP WG list
> can provide even more references.
>
> LISP Delegated Database Tree (LISP DDT) [1] follows a DNS-like structure
> and it's designed to be deployed at Internet scale. For an academic work on
> a DNS-based Mapping System take a look at [2].
>
> Designs leveraging DHTs have also been considered to enable high
> scalabilty, see for instance [3][4]. For a survey on different Mapping
> System options see [5] (I wasn't able to find an open version of this
> article unfortunately).
>
> For those interested in current research efforts, recent works include
> decentralized designs [6] or even Blockchain-based approaches [7].
>
> Hope this helps,
> Alberto
>
> [1] https://tools.ietf.org/html/rfc8111
> [2] http://people.ac.upc.edu/ljakab/2010-jakab-jsac-lisp-tree.pdf
> [3] https://tools.ietf.org/html/draft-cheng-lisp-shdht-04
> [4] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.
> 139.735=rep1=pdf
> [5] http://ieeexplore.ieee.org/document/6422285/
> [6] https://tools.ietf.org/html/draft-farinacci-lisp-decent-00
> [7] https://datatracker.ietf.org/meeting/97/materials/slides-
> 97-lisp-blockchain-based-mapping-system/
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Behcet Sarikaya]

Hi Satoru,

I saw in your presentation you made in Singapore at 5gangip side meeting
that SRv6 needs SDN controller to put SIDs to the nodes with its functions.

Can you elaborate on that?

My concern is that I wonder if 3GPP supports SDN, especially what would be
the south bound interface?

Regards,
Behcet

On Thu, Feb 8, 2018 at 3:00 AM, Satoru Matsushima <
satoru.matsush...@gmail.com> wrote:

> Hello Kalyani,
>
> > [..snip..]
>
> > Your slides 9 – 13 show interactions between UPFs and SMF. There are 2
> kinds of UPFs:
> > Anchor type UPF and service function type UPF. What are the
> functionalities of these?
>
> Please find some functionalities in the SRv6 mobile Uplane draft:
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-00#section-5
>
> When it comes to anchor, it should be equivalent with PSA, PDU Session
> Anchor, in TS23.501 of 3GPP 5G_ph1 terminology.
>
> You would also find various SRv6 functions in the network programming
> draft:
> https://tools.ietf.org/html/draft-filsfils-spring-srv6-
> network-programming-03
>
> Maybe you can see SRv6 mobile uplane as a set of SRv6 functions like a
> SRv6 profile for mobile with some augment.
>
> When it comes to service function type UPF, you name it. Following draft
> exhibits how service chain can be done by SRv6:
> https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-00
>
>
> > What are the changes in SMF functionalities to support SRv6? Is the
> interface between
> > SMF and UPFs based on N4/Sx (PFCP in TS 29.244)?
>
> SMF functionalities seems still work in progress so that I couldn’t say
> clearly what the change to it.
> In CUPS architecture for both Rel-14 and Rel-15, PFCP is expected as Sx
> and N4 for SRv6 Uplane with no change to over-the-wire messages in basic
> mode operation:
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-
> uplane-00#section-8.1
>
>
> > Also you show IPv6/SRv6 nodes in those slides. Are the UPFs ‘overlaid’
> on IPv6/SRv6 nodes?
> > Are these UPFs VNFs? Or are UPFs implemented on IPv6/SRv6 nodes?
> >
>
> When you see UPF specifically it should be controlled by SMF through N4,
> they are not the UPFs.
> But you might see them as UPFs if a SMF doesn’t control them directly but
> the SMF can put the sessions to it through some other means.
> 3GPP SA2 has studied on that case (ETSUN). We consider how SMF deal with
> that case and SRv6 may help to solve the issues to it in simpler way.
> Please let me know if you are interested in.
>
> Cheers,
> --satoru
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Behcet Sarikaya]

On Wed, Feb 7, 2018 at 11:50 AM, Sri Gundavelli (sgundave) <
sgund...@cisco.com> wrote:

> They all look the same, Behcet :-)
>
> You tunnel, it becomes LISP; when you translate it becomes ILA;  When you
> call that mapping table a binding table, and keep it one place, it becomes
> Mobile IPv6.
>
> When you move that table to some cloud and push it/fetch/flood it, they
> all converge :-)
>
>
A strong no, Sri. You are talking about a legacy technology that is already
in place in 4G and now being carried to 5G.
Versus a proposal to totally change it, hopefully sometime later in 5G.

Again, I think it would be more productive to work on the main subject,
i.e. SRv6 user plane proposal by Matsushima.

Regards,
Behcet


> Sri
>
>
>
>
>
> From: Behcet Sarikaya <sarikaya2...@gmail.com>
> Reply-To: "sarik...@ieee.org" <sarik...@ieee.org>
> Date: Wednesday, February 7, 2018 at 9:44 AM
> To: Sri Gundavelli <sgund...@cisco.com>
> Cc: "Bogineni, Kalyani" <kalyani.bogin...@verizonwireless.com>, Marco
> Liebsch <marco.lieb...@neclab.eu>, Dino Farinacci <farina...@gmail.com>, "
> i...@ietf.org" <i...@ietf.org>, dmm <dmm@ietf.org>
>
> Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for
> draft-herbert-ila-mobile-00.txt
>
> Hi Sri,
>
>
> On Wed, Feb 7, 2018 at 11:23 AM, Sri Gundavelli (sgundave) <
> sgund...@cisco.com> wrote:
>
>> Hi Kalyani,
>>
>> For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there
>> are two nodes that's where the translation/tunneling is happening. In a
>> generic sense, it could be a layer-2 termination point, a first-hop router,
>> or a transit router. When seen from 3GPP lens, there is only UPF and the N4
>> interface that you talk about. But, there is N3 (eNB to UPF) and then there
>> are also other nodes where there is an impact.  The
>> translation/tunneling/steering may very well happen on some router
>> connected to the service cloud/core (on N6),  or at some exit router where
>> there is no 3GPP UPF function and there is no N4.
>>
>>
>>
> I find it a bit too simplistic to put these two words
> translation / tunneling
>
> in a sort of unifying manner.
>
> I don't think the reality is that simple, especially when you talk to 3GPP
> people.
>
> In fact the translation or Id/Loc separation systems offer completely
> different and whole new view of how the data plane will work than tunneling
> which is the legacy technology.
>
> On the other hand, draft-ietf-dmm-srv6-mobile-uplane-00 which was
> previously
>
> draft-matsushima-spring-dmm-srv6-mobile-uplane-03
>
> proposes a more efficient way of tunneling.
> I don't see any discussion on the main subject, i.e. SRv6 mobile user
> plane so far on this list and I am puzzled by that.
>
> So my humble suggestion is to concentrate on the advantages and
> disadvantages of SRv6 mobile user plane draft to 3GPP 4G (if there is time
> maybe a bit of 5G). I assure you there is a lot of meat there which should
> keep you busy for a long time.
>
> Regards,
> Behcet
>
>
>> So, there are two key questions here:
>>
>> 1.) Is the UPF only node that is impacted here? Is the assumption that
>> these protocols are doing some translation/tunneling only on UPF node? Or,
>> we can introduce a two types of IP forwarding nodes, one collocated with
>> UPF and another without UPF. I know how this discussion will go in 3GPP;
>> they will insist and say they we will never recognize any other node other
>> what they created.
>>
>> 2.) Is N4 the only interface to these two types of node variants. Or we
>> will have N4’ to these both types of nodes from some AF (which can
>> interwork with the service bus), and we don’t’ touch N4.
>>
>> Marco’s point is to keep this generic and not make this very UPF
>> specific, as it will be too restrictive.
>>
>>
>>
>> Sri
>>
>>
>>
>>
>> From: "Bogineni, Kalyani" <kalyani.bogin...@verizonwireless.com>
>> Date: Tuesday, February 6, 2018 at 1:23 PM
>> To: Marco Liebsch <marco.lieb...@neclab.eu>, Sri Gundavelli <
>> sgund...@cisco.com>, Dino Farinacci <farina...@gmail.com>
>> Cc: "i...@ietf.org" <i...@ietf.org>, dmm <dmm@ietf.org>
>> Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
>> draft-herbert-ila-mobile-00.txt
>>
>> Marco, Sri:
>>
>>
>>
>> Here is the services based 5G architecture.
>>
>>
>>
>>
>>
>> SMF is a control plane 

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Behcet Sarikaya]

Hi Sri,


On Wed, Feb 7, 2018 at 11:23 AM, Sri Gundavelli (sgundave) <
sgund...@cisco.com> wrote:

> Hi Kalyani,
>
> For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there
> are two nodes that's where the translation/tunneling is happening. In a
> generic sense, it could be a layer-2 termination point, a first-hop router,
> or a transit router. When seen from 3GPP lens, there is only UPF and the N4
> interface that you talk about. But, there is N3 (eNB to UPF) and then there
> are also other nodes where there is an impact.  The
> translation/tunneling/steering may very well happen on some router
> connected to the service cloud/core (on N6),  or at some exit router where
> there is no 3GPP UPF function and there is no N4.
>
>
>
I find it a bit too simplistic to put these two words
translation / tunneling

in a sort of unifying manner.

I don't think the reality is that simple, especially when you talk to 3GPP
people.

In fact the translation or Id/Loc separation systems offer completely
different and whole new view of how the data plane will work than tunneling
which is the legacy technology.

On the other hand, draft-ietf-dmm-srv6-mobile-uplane-00 which was previously

draft-matsushima-spring-dmm-srv6-mobile-uplane-03

proposes a more efficient way of tunneling.
I don't see any discussion on the main subject, i.e. SRv6 mobile user plane
so far on this list and I am puzzled by that.

So my humble suggestion is to concentrate on the advantages and
disadvantages of SRv6 mobile user plane draft to 3GPP 4G (if there is time
maybe a bit of 5G). I assure you there is a lot of meat there which should
keep you busy for a long time.

Regards,
Behcet


> So, there are two key questions here:
>
> 1.) Is the UPF only node that is impacted here? Is the assumption that
> these protocols are doing some translation/tunneling only on UPF node? Or,
> we can introduce a two types of IP forwarding nodes, one collocated with
> UPF and another without UPF. I know how this discussion will go in 3GPP;
> they will insist and say they we will never recognize any other node other
> what they created.
>
> 2.) Is N4 the only interface to these two types of node variants. Or we
> will have N4’ to these both types of nodes from some AF (which can
> interwork with the service bus), and we don’t’ touch N4.
>
> Marco’s point is to keep this generic and not make this very UPF specific,
> as it will be too restrictive.
>
>
>
> Sri
>
>
>
>
> From: "Bogineni, Kalyani" 
> Date: Tuesday, February 6, 2018 at 1:23 PM
> To: Marco Liebsch , Sri Gundavelli <
> sgund...@cisco.com>, Dino Farinacci 
> Cc: "i...@ietf.org" , dmm 
> Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
> draft-herbert-ila-mobile-00.txt
>
> Marco, Sri:
>
>
>
> Here is the services based 5G architecture.
>
>
>
>
>
> SMF is a control plane entity and talks to the User plane functions (UPF)
> through N4 interface as specified in 3GPP TS 29.244.
>
>
>
> Here are two variants:
>
>
>
> Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.
>
>
>
>
>
> Option 2: Here there is no direct interface between Mapping Db and UPFs.
> UPFs also support APIs like the control plane functions.
>
>
>
>
>
> The architecture is extensible and additional control plane or user plane
> functions can be added.
>
>
>
> Is this what you had in mind?
>
>
>
> Kalyani
>
>
>
> -Original Message-
> From: ila [mailto:ila-boun...@ietf.org ] On Behalf
> Of Marco Liebsch
> Sent: Tuesday, February 6, 2018 12:09 PM
> To: Sri Gundavelli (sgundave) ; Dino Farinacci <
> farina...@gmail.com>
> Cc: i...@ietf.org; dmm 
> Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
> draft-herbert-ila-mobile-00.txt
>
>
>
> It could be a nice option to keep the data plane specific control (the
> mapping DB you refer to) in the user plane and take a common N4 to update
> the mapping DB in case of mobility. But I think that clashes with the clear
> data plane / control plane separation in nextgen. And: there may be data
> plane solutions which don't come with a control plane / mapping system. For
> these the N4 needs to disseminate complete forwarding states (an more, e.g.
> for chargeable event monitoring, device dormancy support etc.) to all
> relevant data plane nodes, means the ones that hold a state for the mobile.
>
>
>
> Btw, in terms of compatibility with nextgen, so far N4 is terminated only
> in few types of core data plane nodes with a dedicated role. We may
> investigate options to push forwarding and further policies from the
> (nextgen) control plane to other data plane nodes which don't terminate N4.
>
>
>
> marco
>
>
>
> -Original Message-
>
> From: dmm [mailto:dmm-boun...@ietf.org ] On Behalf
> Of Sri Gundavelli (sgundave)
>
> Sent: Dienstag, 6. 

Re: [DMM] white paper for optimized mobile user plane solutions for 5G

[Behcet Sarikaya]

Hi dmm folks,

I think that Kalyani is going to send a revised version of the outtline not
including the items that are not of interest in dmm group.

Regards,

Behcet

On Fri, Dec 15, 2017 at 7:17 PM, Satoru Matsushima <
satoru.matsush...@gmail.com> wrote:

> Hello Kalyani,
>
> +1. White paper looks a good work to start the user-plane study here in
> IETF. I support it.
>
> I think that comparison with quantitive measurements may need to use
> specific deployment metrics in each operator.
>
> But through this white paper work, if we figure out clear criteria for
> apple-to-apple comparison to candidate protocols for 3GPP use cases, that
> would be greatly help to move the study forward.
>
> Hope that make sense and work with you on it.
>
> Cheers,
> --satoru
>
> > 2017/12/14 6:13、Bogineni, Kalyani  VerizonWireless.com>のメール:
> >
> > Folks:
> >
> > In response to the 3GPP CT4 study item on user plane protocols, we
> propose that a white paper
> > be developed that can compare the different IETF protocols. Attached is
> an outline. Please let me
> > know if you would like to contribute.
> >
> > Kalyani Bogineni
> > Verizon
> >
> >  00.docx>___
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP

[Behcet Sarikaya]

Sri,
As I wrote to Marco Thursday afternoon III clashes with 5G IP meeting.
Please do not use that slot :)

Regards,
Behcet

On Wed, Nov 15, 2017 at 10:56 AM, Sri Gundavelli (sgundave) <
sgund...@cisco.com> wrote:

> Thats a great idea. Lets find a slot to discuss with Charlie and
> understand the comments.
>
> Any one interested in attending, send me a unicast note.
>
> Sent from my iPhone
>
> On Nov 15, 2017, at 10:52 AM, Marco Liebsch 
> wrote:
>
> Can we quickly set up an ad-hoc site meeting here at IETF100?
>
> E.g. Thursday Afternoon III or later would be possible for me.
>
> Would be an opportunity to follow-up f2f and further elaborate on that.
>
>
>
> marco
>
>
>
>
>
>
>
>
>
>
>
> *From:* dmm [mailto:dmm-boun...@ietf.org ] *On
> Behalf Of *Sri Gundavelli (sgundave)
> *Sent:* Mittwoch, 15. November 2017 03:42
> *To:* vojislav vucetic
> *Cc:* Charlie Perkins; dmm@ietf.org
> *Subject:* Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work
> in 3GPP
>
>
>
> Like I said, concern is valid. The deliverable about  that study. If it
> turns out there is no significant optimizations that operators can convince
> operators, then we will drop the work.
>
>
>
>
>
> Sri
>
>
>
> *From: *vojislav vucetic 
> *Date: *Tuesday, November 14, 2017 at 6:35 PM
> *To: *Sri Gundavelli 
> *Cc: *Charlie Perkins , "dmm@ietf.org" <
> dmm@ietf.org>
> *Subject: *Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work
> in 3GPP
>
>
>
> He put you on the spot
>
> Sent from my iPhone
>
>
> On Nov 14, 2017, at 7:13 PM, Sri Gundavelli (sgundave) 
> wrote:
>
> Hi Charlie,
>
>
>
> Fair point! As part of these efforts, we need to understand and quantify
> those optimizations. For not all work items, we need blessing from anyone
> before we initiate any new work, we do what the community believes is the
> right thing here. This work is less about building a solution, and more
> about investigation.   This is one of those items where can bring possibly
> great optimizations to the mobile data plane. We lost the signaling war
> (after CDMA2000 ended) for various reasons, less technical and more about
> legacy and other reasons, but that does not mean we will fail every time.
>
>
>
>
>
> Sri
>
>
>
>
>
> *From: *dmm  on behalf of Charlie Perkins <
> charles.perk...@earthlink.net>
> *Date: *Tuesday, November 14, 2017 at 4:43 PM
> *To: *"dmm@ietf.org" 
> *Subject: *[DMM] Fwd: Re: [5gangip] To initiate user-plane study work in
> 3GPP
>
>
>
> Hello folks,
>
> I stumbled across this terrific diagram from email that was sent by
> Satoru-san yesterday.  I think it's an indication that current operators
> are not really asking for a simplified data plane.  Or, at least, that we
> really need to understand under what conditions they would accept an
> IETF-designed simplified data plane before embarking on a solution for
> their needs.
>
> Regards,
> Charlie P.
>
> PS. I hope it is O.K. to forward this email...
>
> ==
>
>
> Alex,
>
>
>
> 
>
> Please take a look at the attached picture which one of the realities
> happened in some operator.
>
>
>
> Cheers,
>
> --satoru
>
> 
>
>
>
> 
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

[Behcet Sarikaya]

On Wed, Nov 15, 2017 at 9:56 AM, Carlos Jesús Bernardos Cano <
c...@it.uc3m.es> wrote:

> Hi,
>
> I support adoption.
>
>
+1

Behcet

> Thanks,
>
> Carlos
>
> On Wed, 2017-11-15 at 00:02 +, Sri Gundavelli (sgundave) wrote:
> > Folks:
> >
> > The following message commences a two week call for opinions on the
> > adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as a
> > DMM Working document.
> >
> > ---
> > The DMM working group is considering adopting the draft, "draft-
> > matsushima-spring-dmm-srv6-mobile-uplane-03” as a working group
> > document. The chairs have polled the room for opinions during
> > IETF100, and it was determined that there is good support for taking
> > up this work. The chairs would like to confirm the same in the
> > mailing list.  Please provide your feedback.
> >
> >
> > Document Link:
> > https://www.ietf.org/id/draft-matsushima-spring-dmm-srv6-mobile-uplan
> > e-03.txt
> >
> > Slides:
> > https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv
> > 6-for-mobile-user-plane/
> >
> > Background:
> > https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-mob
> > ile-data-plane-evolution-motivation-goals/
> > ---
> >
> > Regards
> > Dapping & Sri
> >
> > ___
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] New Version Notification for draft-sarikaya-dmm-for-wifi-05.txt

[Behcet Sarikaya]

Hi all,

We submitted Rev. 05 as shown below.

Chairs; Appreciate a slot in IETF 100.

Regards,
Behcet

A new version of I-D, draft-sarikaya-dmm-for-wifi-05.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:   draft-sarikaya-dmm-for-wifi
Revision:   05
Title:  Distributed Mobility Management Protocol for WiFi Users in
Fixed Network
Document date:  2017-10-30
Group:  Individual Submission
Pages:  22
URL:https://www.ietf.org/internet-drafts/draft-sarikaya-dmm-for-
wifi-05.txt
Status: https://datatracker.ietf.org/doc/draft-sarikaya-dmm-for-
wifi/
Htmlized:   https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-05
Htmlized:   https://datatracker.ietf.org/doc/html/draft-sarikaya-dmm-
for-wifi-05
Diff:   https://www.ietf.org/rfcdiff?url2=draft-sarikaya-dmm-for-
wifi-05

Abstract:
   As networks are moving towards flat architectures, a distributed
   approach is needed to mobility management.  This document presents a
   use case distributed mobility management protocol called Distributed
   Mobility Management for Wi-Fi.  The protocol is based on mobility
   aware virtualized routing system with software-defined network
   support.  Routing is in Layer 2 in the access network and in Layer 3
   in the core network.  Smart phones access the network over IEEE
   802.11 (Wi-Fi) interface and can move in home, hotspot and enterprise
   buildings.




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
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Behcet Sarikaya]

Lorenzo,
It is 3GPP practice (or law, should I say) is to assign a prefix in
IPv6 to the UE. That is what Peter is talking about.

Regards,

Behcet

On Fri, Dec 2, 2016 at 2:12 PM, Peter McCann  wrote:
> With a fixed access network the prefix can be assigned to the link and used
> by anyone who joins the link.
>
>
>
> With a prefix offering mobility the prefix belongs to the mobile host and
> needs to move with it.  There aren’t enough prefixes (even in IPv6) to
> assign a permanent prefix to each UE for every topological attachment point
> that it might visit or start a session from.
>
>
>
> -Pete
>
>
>
>
>
> From: Lorenzo Colitti [mailto:lore...@google.com]
> Sent: Friday, December 02, 2016 3:09 PM
> To: Peter McCann 
> Cc: jouni.nospam ;
> draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> But you have that problem with IP addresses as well, right? I don't see how
> "assigning a prefix with certain properties" requires more state in the
> network than "assigning an IP address with certain properties".
>
>
>
> On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann 
> wrote:
>
> Providing any kind of mobility service for a prefix will require some state
> somewhere in the network.  It would be great to avoid an allocation request
> / response for the prefix, but the state has to be created somehow before
> the UE can use the prefix and it has to be reclaimed eventually after the UE
> stops using the prefix (which may not be until well after it disconnects
> from the current link and moves to another one).
>
>
>
> Would welcome any suggestions on how to manage this state.
>
>
>
> -Pete
>
>
>
>
>
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Lorenzo Colitti
> Sent: Friday, December 02, 2016 12:04 PM
> To: jouni.nospam 
> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> Hi,
>
>
>
> I like the goal of reducing network cost by allowing the use of IP addresses
> that do not require network mobility, but we should not be doing this by
> requesting IP addresses from the network, because this violates IPv6 address
> assignment best practices.
>
>
>
> Specifically, RFC 7934 recommends that a) the network should provide
> multiple addresses from each prefix and b) the network should allow the host
> to use new addresses without requiring explicit requests to the network.
> This is in conflict with at least this text in the draft, which says:
>
>
>
>In case an application
>
>requests one, the IP stack shall make an attempt to configure one by
>
>issuing a request to the network.  If the operation fails, the IP
>
>stack shall fail the associated socket request
>
>
>
> One way to resolve this conflict would be to say that the network must not
> assign individual addresses, but /64 (or shorter) prefixes. So if the device
> desires to use fixed IPv6 addresses, then the network should give the host a
> fixed IPv6 prefix from which the host can form as many addresses as it
> wants.
>
>
>
> I do not think we should advance this document until the conflicts are
> resolved. This document is about IPv6 address assignment to mobile nodes,
> and we should not publish a document about IPv6 address assignment that
> conflicts with best current practices on IPv6 address assignment.
>
>
>
> Regards,
>
> Lorenzo
>
>
>
> On Mon, Nov 28, 2016 at 12:56 PM, jouni.nospam 
> wrote:
>
> Folks,
>
>
>
> The authors of draft-ietf-dmm-ondemand-mobility-07 and
> draft-sijeon-dmm-use-cases-api-source have come up with a merged document
> draft-ietf-dmm-ondemand-mobility-08.
>
>
>
> This email starts a 2 week WGLC for draft-ietf-dmm-ondemand-mobility-08.
>
> The WGLC starts 11/28/16 and ends 12/12/16.
>
>
>
> Provide your comments, concerns and approvals to the email list (and
> hopefully also to IssueTracker).
>
>
>
> - Jouni & Dapeng
>
>
>
>
>
>
>
> Begin forwarded message:
>
>
>
> From: IETF Secretariat 
>
> Subject: IETF WG state changed for draft-ietf-dmm-ondemand-mobility
>
> Date: November 28, 2016 at 12:51:34 PM PST
>
> To: , ,
> 
>
> Resent-From: 
>
> Resent-To: jouni.nos...@gmail.com, maxpass...@gmail.com
>
>
>
>
> The IETF WG state of draft-ietf-dmm-ondemand-mobility has been changed to
> "In WG Last Call" from "WG Document" by Jouni Korhonen:
>
> https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
>
>
> Comment:
> WGLC starts 11/28/16 and ends 12/12/16.
>
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
>
>
>
> ___
> dmm 

Re: [DMM] DMM FPC I-D - Implementation

[Behcet Sarikaya]

On Fri, Aug 26, 2016 at 3:00 PM, Bertz, Lyle T [CTO]
 wrote:
> All,
>
>
>
> Last week at the Intel Developer Forum in San Francisco (US), Intel and
> Sprint demonstrated a virtual Evolved Packet Core (vEPC) that included,
> amongst other features, a SGW and PGW (3GPP functions similar to MAG and
> LMA).   This software
>
> 1.   Used a Separated Control and Dataplane Node with an intermediate
> SDN Controller – Opendaylight’s Beryllium release.
>
> 2.   Used IETF DMM FPC-v03
> (https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/?include_text=1)
> for communication of some sessions (others were simulated to ensure we met
> the demonstration timelines).
>
>
>
> The Control and Dataplane software performs well (10Gbps down / 3Gbps up for
> 250K users) on a single Intel processor’s *core* based upon the open source
> DPDK libraries from Intel.  The demonstration shows the promise of
> separation of Control and Data planes.
>

I think that 3GPP already implemented control and data plane separation.

Regards,

Behcet
>
>
> We had to deviate quite a bit from the version 03 specification to support
> 3GPP but version 04 adds the 3GPP model as an option.  Many of the general
> changes in version 04 are influenced by the implementation.
>
>
>
> Work is already underway to implement version 04 with several internal
> changes, e.g. moving from the Opendaylight MD-SAL (model driven) approach to
> the application driven (AD-SAL) approach, as focus is now on performance.  I
> hope to share more details in the future.  As a part of the final version of
> the FPC I-D we will submit an Implementation Status section in the draft per
> RFC 7942.
>
>
>
> Lyle Bertz
>
> Sprint
>
>
> 
>
> This e-mail may contain Sprint proprietary information intended for the sole
> use of the recipient(s). Any use by others is prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies of the
> message.
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] draft-ietf-dmm-ondemand-mobility-05

[Behcet Sarikaya]

On Wed, Jun 29, 2016 at 4:04 PM, Jouni Korhonen <jouni.nos...@gmail.com> wrote:
> o Exposing mobility state to mobile nodes and network nodes:
>   define solutions that allow, for example, mobile nodes to select
>   either a care-of address or a home address depending on an
>   application' mobility needs. In order to enable this
>
> To me it is there..
>
>   functionality, the network-side control functions and other
>   networking nodes must also be able to exchange appropriate
>   control information, as well as to the mobile nodes and their
>   applications.
>
> And again here.
>
> If apps or mobile node need to be able to select appropriate address I find
> it ok to describe it.. call it api or not in the charter.
>
> - Jouni
>

Not to me.

I don't see any API. The API RFC 5014 was done in 6man. mif WG used to
do API. mif WG had clear items on API in its charter.






Regards,

Behcet
>
>
>
> 6/29/2016, 1:12 PM, Behcet Sarikaya kirjoitti:
>>
>> On Wed, Jun 29, 2016 at 3:03 PM, Jouni Korhonen <jouni.nos...@gmail.com>
>> wrote:
>>>
>>> Lo and behold your cry for intended status change will happen!
>>>
>>
>>
>> Lo I just now checked it.
>> I could not see any API development in dmm charter.
>>
>> Aren't you responsible for this?
>>
>> Regards,
>>
>> Behcet
>>>
>>> Actually, this came up earlier because 1) the I-D makes a normative
>>> referecence to an informational RFC5014 and 2) API documents are
>>> informational in general. It just did not make to the latest revision..
>>>
>>
>>
>>> - JOuni
>>>
>>>
>>> 6/29/2016, 9:07 AM, Behcet Sarikaya kirjoitti:
>>>>
>>>>
>>>>  Hi all,
>>>>
>>>> I quickly looked at this draft.
>>>> It seems like the authors or Danny changed "sustained IP address" to
>>>> "session lasting IP address". It sounds a bit better.
>>>> However, my concerns about sustained IP address remain the same on the
>>>> session lasting IP address because semantically they mean the same
>>>> thing, the session lasting is just a more flashy name.
>>>>
>>>> I really don't understand how in the world this draft became a WG
>>>> draft in the first place. Given that, my suggestion is to finish up
>>>> this work by changing it to Informational. I don't believe it is
>>>> implementable.
>>>>
>>>> This draft is also not the type of draft dmm should be working on, dmm
>>>> I think is a continuation of MIP related mobility WGs and this draft
>>>> has nothing to do with this.
>>>>
>>>> Make it Informational, folks.
>>>>
>>>> Behcet
>>>>
>>>> ___
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] draft-ietf-dmm-ondemand-mobility-05

[Behcet Sarikaya]

On Wed, Jun 29, 2016 at 3:03 PM, Jouni Korhonen <jouni.nos...@gmail.com> wrote:
> Lo and behold your cry for intended status change will happen!
>


Lo I just now checked it.
I could not see any API development in dmm charter.

Aren't you responsible for this?

Regards,

Behcet
> Actually, this came up earlier because 1) the I-D makes a normative
> referecence to an informational RFC5014 and 2) API documents are
> informational in general. It just did not make to the latest revision..
>


> - JOuni
>
>
> 6/29/2016, 9:07 AM, Behcet Sarikaya kirjoitti:
>>
>>  Hi all,
>>
>> I quickly looked at this draft.
>> It seems like the authors or Danny changed "sustained IP address" to
>> "session lasting IP address". It sounds a bit better.
>> However, my concerns about sustained IP address remain the same on the
>> session lasting IP address because semantically they mean the same
>> thing, the session lasting is just a more flashy name.
>>
>> I really don't understand how in the world this draft became a WG
>> draft in the first place. Given that, my suggestion is to finish up
>> this work by changing it to Informational. I don't believe it is
>> implementable.
>>
>> This draft is also not the type of draft dmm should be working on, dmm
>> I think is a continuation of MIP related mobility WGs and this draft
>> has nothing to do with this.
>>
>> Make it Informational, folks.
>>
>> Behcet
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] draft-ietf-dmm-ondemand-mobility-05

[Behcet Sarikaya]

 Hi all,

I quickly looked at this draft.
It seems like the authors or Danny changed "sustained IP address" to
"session lasting IP address". It sounds a bit better.
However, my concerns about sustained IP address remain the same on the
session lasting IP address because semantically they mean the same
thing, the session lasting is just a more flashy name.

I really don't understand how in the world this draft became a WG
draft in the first place. Given that, my suggestion is to finish up
this work by changing it to Informational. I don't believe it is
implementable.

This draft is also not the type of draft dmm should be working on, dmm
I think is a continuation of MIP related mobility WGs and this draft
has nothing to do with this.

Make it Informational, folks.

Behcet

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] OnDemand draft: 3 address types discussion

[Behcet Sarikaya]

Hi Danny,

This is my reply to all your mails. I hope it clarifies the air.

I read RFC 5014 and I think that on-demand mobility as I and it seems
like as 3GPP understands is already there:

IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_COA

are all we need.
So if UE wants mobility, it sets  IPV6_PREFER_SRC_HOME and as a result
gets the fixed IP address as you call it or it gets anchored mobility
service.

If UE does not want mobility, it sets IPV6_PREFER_SRC_COA then it gets
the nomadic IP address.

Note that in the case of mobility, UE may still get nomadic address
and mobility, that is another issue.

Therefore RFC 5014 is good enough, the authors, all good friends of
this community have done a good job.

Regards,

Behcet


On Tue, May 3, 2016 at 7:27 AM, Moses, Danny  wrote:
>
> This is in reply to comments we received from Behcet and Suresh regarding
> the three types of addresses define in the draft. Suresh commented that the
> ‘Fixed IP address’ is not necessary and application only require to select
> Sustained or Nomadic IP addresses and Behcet commented that the ‘Sustained
> IP address’ is not needed and not well define due to the fact that the draft
> does not define how to identify the end of an IP session (will be discussed
> in a separate email).
> We have gave more thought to these types and concluded that the definitions
> in the spec were confusing. We are providing new text in the new version,
> hoping they are more clear.
> We re-evaluated whether to stay with the definition of three IP address
> types or move to a two IP address type scheme and eventually concluded that
> it is better to stay with the three type alternative. We hope that the
> better text in the new draft version will clarify and here are some
> additional inputs:
> Nomadic IP address (or in its new name: Non-persistent IP address):
> Clearly this type is useful for all applications that do not require any IP
> session continuity guarantee from the network and wish to avoid the overhead
> introduced by the network as part of that guarantee (inefficient routes,
> tunneling etc…).
> Sustained IP address (or in its new name: Session-lasting IP address):
> This is our accurate definition for the IP session continuity service that
> some application require and is similar to what is provided today by
> default, by mobile operators via GTP or PMIP. Basically, current
> implementations provide  a guarantee for the source IP address to be valid
> throughout the time the mobile host is connected to the mobile network.
> We concluded that mobile hosts do not really require such a guarantee. It is
> sufficient to require a guarantee of the IP address availability while there
> is/are an IP session(s) using this IP address and hence the more accurate
> definition. Furthermore, some WG members have shown cases in DMM where it is
> more efficient for applications to request a new Session-lasting IP address
> when launched rather than using an existing one that was allocated to the
> mobile host in the past. This is due to possible movement of the mobile host
> to a LAN which is being served by a mobility anchor that is different from
> the one that was used when the older Session-lasting IP address was assigned
> to the mobile host.
> Fixed IP address (no renaming …):
> We believe that this is where our original text was the most unclear leading
> to the confusion on the mailing list and the comments from the flour. A
> Fixed IP address is guaranteed by the network to Always be valid, even if
> the mobile host is not utilizing any IP sessions, or has been disconnected
> from the network for some time. This is a special service that mobile
> network operators provide for a premium charge, for servers, VPNs , secured
> content and other applications. With this IP address type the network
> operator provide IP address reachability in addition to IP session
> continuity, and mobile hosts may register these addresses in DNS
> infrastructure for name resolution.
> Clearly, most mobile hosts do not require Fixed IP addresses and their
> owners will not pay the premium cost for this service, but still, it is a
> service that mobile operators provide and this is enough proof for us to
> acknowledge its need. Please see some examples from
> AT -
> https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-addressing.jsp,
> Verizon -
> http://www.verizonwireless.com/businessportals/support/features/data_services/static_ip.html
> and Sprint -
> https://www.sprint.com/business/solutions/sprint_enablers/sprint_datalink_and_static_ip/index.html#.VxC7xSN9480
> providing this service (which is called: Static IP address)
> Regards,
> Alper and Danny
>
>
> -
> A member of the Intel Corporation group of companies
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by 

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Behcet Sarikaya]

On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon <seilj...@gmail.com> wrote:
> Hi Behcet,
>
> As I was not there, what discussions was given.
> However, let me speak a few words.
>
> The specs. you referenced seems talking about need of different levels of
> mobility support, e.g. high/medium/low mobility and so on.


I am looking at Rev 0.3, they no longer have those.
I am hearing that Rev 0.4 is being worked out and maybe posted
sometime next week.
I hope this clarifies.

Behcet

> Within the frame, I think having a proper level of mobility support based on
> IP session continuity and IP address reachability for an application, with
> the defined source IP address type request will make sense in the scope of
> mobility support in the specs.
>
> Besides, as you know, the spec. currently remains at 0.2 version, describing
> work items briefly and concisely. It doesn't constraint potentials for
> on-demand mobility. And we don't know how/where the direction will be going.
>
> Regards,
> Seil Jeon
>
> -Original Message-----
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, April 19, 2016 4:52 PM
> To: Jouni Korhonen <jouni.nos...@gmail.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hello Folks,
>
> At IETF 95 session, there was some discussion on the mention of on demand
> mobility in 3GPP 5G documents, e.g. 23.799.
>
> It seems like 3GPP meaning of on demand mobility is that the UE asks or
> demands mobility support or not.
>
> So that has nothing to do with the sustained IP addresses.
>
> Regards,
>
> Behcet
>
> On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen <jouni.nos...@gmail.com>
> wrote:
>> Folks,
>>
>> This mail starts two week WGLC for the I-D:
>>
>> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01
>>
>> The WGLC ends 12/15/2015.
>>
>> Provide your reviews and comments to the mailing list. For the better
>> tracking of issues and proposed changed use the Issue Tracker to
>> submit your issues/proposals.
>>
>> - Jouni & Dapeng
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Behcet Sarikaya]

On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon <seilj...@gmail.com> wrote:
> Hi Behcet,
>
> As I was not there, what discussions was given.
> However, let me speak a few words.
>
> The specs. you referenced seems talking about need of different levels of
> mobility support, e.g. high/medium/low mobility and so on.
> Within the frame, I think having a proper level of mobility support based on
> IP session continuity and IP address reachability for an application, with
> the defined source IP address type request will make sense in the scope of
> mobility support in the specs.
>

Did I say below that it does or does not say these things?

What I said is the current thinking is to tie it to the UE asking for
mobility support or not.

If you have time, I would recommend spending it on coming up with a
solution for the so-called sustained IP address.

Behcet
> Besides, as you know, the spec. currently remains at 0.2 version, describing
> work items briefly and concisely. It doesn't constraint potentials for
> on-demand mobility. And we don't know how/where the direction will be going.
>
> Regards,
> Seil Jeon
>
> -Original Message-----
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, April 19, 2016 4:52 PM
> To: Jouni Korhonen <jouni.nos...@gmail.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hello Folks,
>
> At IETF 95 session, there was some discussion on the mention of on demand
> mobility in 3GPP 5G documents, e.g. 23.799.
>
> It seems like 3GPP meaning of on demand mobility is that the UE asks or
> demands mobility support or not.
>
> So that has nothing to do with the sustained IP addresses.
>
> Regards,
>
> Behcet
>
> On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen <jouni.nos...@gmail.com>
> wrote:
>> Folks,
>>
>> This mail starts two week WGLC for the I-D:
>>
>> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01
>>
>> The WGLC ends 12/15/2015.
>>
>> Provide your reviews and comments to the mailing list. For the better
>> tracking of issues and proposed changed use the Issue Tracker to
>> submit your issues/proposals.
>>
>> - Jouni & Dapeng
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Behcet Sarikaya]

Hello Folks,

At IETF 95 session, there was some discussion on the mention of on
demand mobility in 3GPP 5G documents, e.g. 23.799.

It seems like 3GPP meaning of on demand mobility is that the UE asks
or demands mobility support or not.

So that has nothing to do with the sustained IP addresses.

Regards,

Behcet

On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen  wrote:
> Folks,
>
> This mail starts two week WGLC for the I-D:
> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01
>
> The WGLC ends 12/15/2015.
>
> Provide your reviews and comments to the mailing list. For the better
> tracking of issues and proposed changed use the Issue Tracker to submit your
> issues/proposals.
>
> - Jouni & Dapeng
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Behcet Sarikaya]

I am hoping that someone can show me a protocol that exists in some
form, maybe a draft, that implements fine-grained anchoring as
required by Sustained IP Addresses.

We will write sometime in the future is not acceptable, then this and
similar drafts have to wait until that time comes.

One implication of this is such a protocol is willing to cope with the
host routes.

Behcet



On Wed, Apr 6, 2016 at 7:42 AM,  <pierrick.se...@orange.com> wrote:
> Hi Dany,
>
> I support this I-D. I find the document very useful, and well written. We all 
> agree that mobility management must be activated on purpose,  it likely 
> requires an enhanced source address selection framework where applications 
> can obtain IP address with specific properties. By allowing applications to 
> request prefix properties, this I-D is clearly a part of this framework. 
> Maybe the document could be better by stressing clearly that it should be 
> used together with solutions allowing the network to expose prefix properties 
> to the host, for example with draft-korhonen-dmm-prefix-properties and 
> draft-moses-dmm-dhcp-ondemand-mobility, which are somehow complementary... 
> Like I said, it is  a framework :-)
>
>
> BR,
> Pierrick
>
>> -Message d'origine-
>> De : dmm [mailto:dmm-boun...@ietf.org] De la part de Moses, Danny
>> Envoyé : jeudi 31 mars 2016 18:44
>> À : sarik...@ieee.org
>> Cc : dmm@ietf.org
>> Objet : Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>>
>> Hi,
>> Good, see my reply inline (surrounded by >>>>>>>>>>>>) .
>>
>> Thanks again for investing the time to review the drafts,
>>   /Danny
>>
>> -Original Message-
>> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
>> Sent: Wednesday, March 30, 2016 12:12
>> To: Moses, Danny
>> Cc: dmm@ietf.org
>> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>>
>> Hi Danny,
>>
>> I am removing all previous conversation because it all got mixed up.
>> Let's start afresh.
>>
>>
>> I read you dhcp draft also.
>>
>> There is confusion in several levels. Your API draft talks about different
>> applications on a MN needing different types of mobility services. Your 
>> DHCPv6
>> draft seems to give a solution on how a host can get different types of
>> addresses/prefixes from DHCPv6 server, so is it for a host or an application?
>> Prefix or address is assigned for an interface, that is another well known 
>> concept
>> which your draft seem to completely ignore, i.e. a host may have multiple
>> interfaces.
>> DM>>>>>>>>>>>>>>>>>>>>>>
>> Yes, I understand were the confusion might arise. The only entity in the 
>> host (or -
>> mobile device) which uses DHCP is the DHCP client that is part of the TCP/IP
>> stack. There may be several triggers to cause the DHCP client to request a 
>> source
>> IP address:
>>  - When the mobile node initially attaches to a network.
>>  - When the mobile node moves to a different location and needs to refresh 
>> its
>> source IP address.
>> The On-Demand concept implies a new trigger:
>>  - When an application is launched, opens an IP Socket and requires a 
>> special type
>> of source IP address which was not already assigned to the mobile node.
>> So, it is the responsibility of the TCP/IP stack in the mobile node to 
>> figure out
>> when it is required to initiate a DHCP transaction to serve the 
>> application's needs.
>>
>> Regarding multiple interface, you are correct once more. A mobile node may 
>> have
>> multiple interfaces. When this occurs, the mobile node needs to send at 
>> least one
>> DHCP request on each interface and the network assigns the source IP address 
>> to
>> the interface from which the DHCP request had arrived. This is not new and 
>> the
>> DHCP draft does not mention it because there are no changes or extensions
>> required.
>> >>>>>>>>>>>>>>>>>>>>>>>>>DM
>>
>> Another concept is (as I already mentioned) topological correctness.
>> If MN changes subnet, its previous prefix becomes topologically incorrect. 
>> Either it
>> has to get a new prefix or there must be some system support, e.g. host 
>> routes.
>> Of course another case is anchoring, like in 3GPP or in MIP. If you are 
>> anchored
>> your prefix does not change.
>>
>> So you seem to ignore all these and instead i

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Behcet Sarikaya]

Hi Danny,

I am removing all previous conversation because it all got mixed up.
Let's start afresh.


I read you dhcp draft also.

There is confusion in several levels. Your API draft talks about
different applications on a MN needing different types of mobility
services. Your DHCPv6 draft seems to give a solution on how a host can
get different types of addresses/prefixes from DHCPv6 server,
so is it for a host or an application?
Prefix or address is assigned for an interface, that is another well
known concept which your draft seem to completely ignore, i.e. a host
may have multiple interfaces.

Another concept is (as I already mentioned) topological correctness.
If MN changes subnet, its previous prefix becomes topologically
incorrect. Either it has to get a new prefix or there must be some
system support, e.g. host routes.
Of course another case is anchoring, like in 3GPP or in MIP. If you
are anchored your prefix does not change.

So you seem to ignore all these and instead introduce three types of
addresses among which the sustained IP address/prefix is the key to
your solution.

Sustained address/prefix has this magical property:
 the IP address used at the beginning of the session remains usable
despite the movement of the mobile host.

and then you say

access network anchoring, corresponding network anchoring, or some
   other solution
can provide sustained address/prefixes.
what does corresponding network anchoring mean?

I have a feeling that what your drafts are saying that right now we
don't know but we anticipate in the future some ways will be found to
make sustained IP addresses.
Is this true?

BTW, your DHCPv6 draft says that DHCPv6 server can give me a Sustained
address/prefix but it does not say how it will be different than the
fixed one?

Suppose we want to develop an access network anchoring for sustained
IP addresses.
What about the needs for signaling? I have a feeling that a host
running very many applications, like in today's smart phones, and so
many smart phones in the system that is going to involve huge amount
of signaling to get/release sustained address/prefixes, right?

My conclusion from all of the above is that, I think what you propose
sounds like a flashy idea but it seems to me that the complications
involved in any solution is intractable.
Unless you can show me otherwise.

 Regards,

Behcet

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Behcet Sarikaya]

On Sat, Mar 26, 2016 at 10:31 AM, Moses, Danny <danny.mo...@intel.com> wrote:
> Hi Behcet,
>
> Please see my reply in the text.
>
> Thanks,
> /Danny
>
> -Original Message-
> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
> Sent: Friday, March 25, 2016 22:00
> To: Dave Dolson
> Cc: Moses, Danny; dmm@ietf.org
> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hi Danny,
>
> I was reading Dave's concerns.
> In my view the real problem in this draft is not with the nomadic IP address, 
> actually Dave's concern was very syntactic.
> I have a semantic concern with the sustained IP address.
> What really is this?
> Sustained IP address is very important for this draft because everything is 
> based on that.
> Reading Section 3.1, Sustained IP Address is kind of a banana, it has the 
> taste that the beholder wants to get. It could be Fixed IP Address or nomadic.
> If Sustained IP Address gets me what I want, i.e. IP session continuity, why 
> do I need anything else?
>
> DM> I am not sure I fully understood your comment/question here. I hope my 
> reply is sufficient.
> DM>I did not understand your attempt to find resemblance between a sustained 
> IP address and a Banana. I also do not understand why you write that it could 
> be a Fixed IP address or a Nomadic IP address. It certainly cannot. What 
> should we modify in section 3.1 to make the distinguish between the different 
> types of services provided to each type of address more clearer?
> DM>If a Sustained IP address gets you what you want - choose it when your 
> application establishes a Socket. If on the other hand, a Nomadic IP address 
> gets you what you want, choose Nomadic when your application establishes a 
> Socket. If you only write applications that require Sustained IP addresses, 
> always choose them when establishing Sockets. But, as we claim in the draft, 
> there are different types of applications in the sense of the IP session 
> continuity they require from the network.

Behcet: You are assigned an address, how do you know it is
Sustained/fixed/nomadic IP address?

Next Q: As for nomadic, I understand that I change my address when my
network changes, i.e. I avoid having topologically incorrect address.
For fixed, I keep my address even if my network changes.
What is the sustained address case?

I think your draft should better use these types (topologically
correct, etc.) concepts to make sense and be understandable.

> DM>Some application do not require IP session continuity services from the 
> network and should not be required to endure the overhead accompanied by that 
> service (Tunneling overhead, un-optimal routs etc..). This draft enables 
> application to convey the type of service they require, and may lead to 
> significant reduction of overhead when the above services are not required.
>

Behcet: I understand the API extension part of your draft, but I don't
understand why you need it. You should clearly explain the use case.
Currently, the main idea is to get sustained IP address but it is not
explained how the application gets a sustained address because it is
not known?
Without a clear case, I don't think the extension is warranted.

> It says in the draft, it may be configured by using access network anchoring, 
> corresponding network anchoring, or something else, whatever that is?
> Which access network are you talking about? Is it good old 3GPP? Then, the 
> answer is yes but then what type of new solution is this?
> DM> This draft does not list the various ways of achieving IP session 
> continuity as required for a Sustained IP address. It's true that current 
> cellular networks use tunneling but other methods could be implemented in the 
> future. We do not want to limit the definition of the different services to a 
> specific radio technology.
>
> I think what this draft is trying to say is if I am in 3GPP coverage area I 
> use 3GPP anchoring, if I am in Wi-Fi coverage area, I use MIPv6. Is this what 
> you had in mind?
> DM> Actually it does not say anything about the means of enabling Sustained 
> IP addresses. It only defines what the different services are, and defines 
> extension to the existing Socket interface, to enable applications specify 
> the type of IP continuity service they need.
>

Behcet: Yes but without explaining what is sustained address, I don't
think you can justify the extension. So the draft needs a strong
justification and use case text.

> I do not recall under which category does this draft fall? Is it a 
> maintenance type of draft? Or is it dmm type of draft?
> DM>It’s a DMM draft
>
Behcet: So no fixed anchoring in e.g. 3GPP is assumed?


> Regards,
>
> Behcet
>
> On Sun, Feb 21, 2

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Behcet Sarikaya]

Hi Danny,

I was reading Dave's concerns.
In my view the real problem in this draft is not with the nomadic IP
address, actually Dave's concern was very syntactic.
I have a semantic concern with the sustained IP address.
What really is this?
Sustained IP address is very important for this draft because
everything is based on that.
Reading Section 3.1, Sustained IP Address is kind of a banana, it has
the taste that the beholder wants to get. It could be Fixed IP Address
or nomadic.
If Sustained IP Address gets me what I want, i.e. IP session
continuity, why do I need anything else?
It says in the draft, it may be configured by using access network
anchoring, corresponding network anchoring, or something else,
whatever that is?
Which access network are you talking about? Is it good old 3GPP? Then,
the answer is yes but then what type of new solution is this?

I think what this draft is trying to say is if I am in 3GPP coverage
area I use 3GPP anchoring, if I am in Wi-Fi coverage area, I use
MIPv6. Is this what you had in mind?

I do not recall under which category does this draft fall? Is it a
maintenance type of draft? Or is it dmm type of draft?

Regards,

Behcet

On Sun, Feb 21, 2016 at 8:05 PM, Dave Dolson  wrote:
> >From an application developer's point of view, I don't think there should be 
> >a distinction about roaming between providers or with the same provider.
> It should work with WiFi, mobile, even wired Ethernet.
> E.g., as I unplug my laptop from work, use the 3G stick on the train, WiFi in 
> the coffee shop and plug in wired Ethernet at home. I could have a fixed 
> address as well as several temporary (no guarantee) addresses.
>
> I'm not saying all of those access technologies need to have implementation 
> of all types of addresses.
> One might only get a fixed address from one of those providers, all the 
> others being no-guarantee.
>
> -Dave
>
> 
> From: Moses, Danny [danny.mo...@intel.com]
> Sent: Sunday, February 21, 2016 10:05 AM
> To: Dave Dolson; dmm@ietf.org
> Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hi Dave,
>
> Regarding the term "Nomadic" IP address:
> Actually, this draft is about enhancements to the Socket API that are useful 
> in relation with movement of the mobile host. Its intent was to notify the 
> access network as to the type of IP session continuity it requires upon 
> movement between LANs. The idea is to reduce the network support for session 
> continuity (via PMIP, GTP, etc) when it is not needed. This draft is not 
> dealing with devices migrating from one service provider to another as other 
> issues should be handled in such scenario.
>
> "Local" is not good as it clashes with IPv6 Local addresses.
>
> The best term in my mind would be: "An IP address without any NW guarantee to 
> continue to be valid after a potential host movement to a new LAN with a 
> different IP prefix". So far, we could not come with a good name for such an 
> address. May be "Guarantee-less"?
>
> Let's not forget: this is going to be used by application developers who do 
> not necessarily fully understand how networks allocate IP addresses and 
> maintain their validity.
>
> Regarding when On-Demand resolution occurs (Point 6):
> How about if we say:
>
> If applications want to influence the type of IP address their generated 
> traffic will use, they must do so after creating a Socket and prior to 
> generating the first transmitted packet.
>
> We do not want to be too specific since it is not a user's manual.
>
> Does this sound reasonable to you?
>
> Thanks,
> /Danny
>
> -Original Message-
> From: Dave Dolson [mailto:ddol...@sandvine.com]
> Sent: Thursday, February 18, 2016 22:46
> To: Moses, Danny; dmm@ietf.org
> Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Danny and Alper,
> Thanks. I hope your helpful explanations below make it into the draft as well.
>
>
> On the "nomadic address" question, this name really feels wrong to me. The 
> address doesn't move and hence isn't nomadic.
> You don't like "ephemeral" because it doesn't convey movement.
> But a question, does the host have to move for the principles of this 
> document to apply?
> Couldn't a host get a new address (perhaps from a different wireless 
> provider) without moving?
> Maybe "non-nomadic address" or "provider-local address" ?
>
>
> On point 6, yes I think you have to specify when the resolution occurs, since 
> it affects which functions return error codes.
> I don't think the local address can be resolved before connect(), since the 
> choice of local address may depend on the remote address to connect. E.g., 
> connections to a peer on a local LAN subnet need to use an address on that 
> interface.
>
>
> -Dave
>
>
>
>
> -Original Message-
> From: Moses, Danny [mailto:danny.mo...@intel.com]
> Sent: Thursday, February 18, 2016 9:13 AM
> To: Dave Dolson; dmm@ietf.org
> 

[DMM] New Version Notification for draft-sarikaya-dmm-for-wifi-04.txt

[Behcet Sarikaya]

 Hi all,

We submitted Rev 04 of DMM 4 WiFi draft as follows.
Your comments will be appreciated.

Regards,

Behcet


A new version of I-D, draft-sarikaya-dmm-for-wifi-04.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:   draft-sarikaya-dmm-for-wifi
Revision:   04
Title:  Distributed Mobility Management Protocol for WiFi
Users in Fixed Network
Document date:  2016-03-15
Group:  Individual Submission
Pages:  23
URL:
https://www.ietf.org/internet-drafts/draft-sarikaya-dmm-for-wifi-04.txt
Status: https://datatracker.ietf.org/doc/draft-sarikaya-dmm-for-wifi/
Htmlized:   https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-04
Diff:   https://www.ietf.org/rfcdiff?url2=draft-sarikaya-dmm-for-wifi-04

Abstract:
   As networks are moving towards flat architectures, a distributed
   approach is needed to mobility management.  This document defines a
   distributed mobility management protocol called Distributed Mobility
   Management for Wi-Fi protocol.  The protocol is based on mobility
   aware virtualized routing system with software-defined network
   support.  Routing is in Layer 2 in the access network and in Layer 3
   in the core network.  Smart phones access the network over IEEE
   802.11 (Wi-Fi) interface and can move in home, hotspot and enterprise
   buildings.




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

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] conclusion of adoption calls

[Behcet Sarikaya]

Hi Jouni,


On Mon, Jan 11, 2016 at 2:55 PM, Jouni Korhonen <jouni.nos...@gmail.com> wrote:
> 
>
> This thread is starting to sound like a broken record. We are chartered to
> have the maintenance responsibility of Mobile IPv6 protocol family. Once the
> chairs see absence of "maintenance oriented" documents that responsibility
> will be terminated. Till then, if someone does not like Mobile IPv6 protocol
> family work being done - just defer contributing. That's the natural way of
> aging out topics in IETF. Enough of this for now!
>
> Another data point to add here. To my (probably misguided?) understanding
> PMIP6 has more live deployments than MIP6 today. My understanding is that
> there are still operators running PMIP6 based networks and some vendors
> developing networking gear with PMIP6 support.
>

This paragraph conflicts the first one, now you are opening another
discussion point.

Can you please kindly be more specific?

Respectfully yours,

Behcet
> - Jouni
>
>
> 1/11/2016, 9:47 AM, Behcet Sarikaya kirjoitti:
>>
>> On Mon, Jan 11, 2016 at 11:23 AM, Thierry Ernst <thierry.er...@inria.fr>
>> wrote:
>>>
>>>
>>> The purpose of conference papers is to do research, so I don’t see how
>>> conferences papers would help to do … maintenance of IETF RFCs. In addition
>>> to bug fixes, MIPv6 and NEMO need to be progressed in the IETF hierarchy of
>>> standards. There are issues and options to be discussed, probably even
>>> extensions; a WG must host such work. My take is that dmm is the right
>>> candidate WG for this to happen.
>>>
>>
>> I still don't see any statements from you on the real need or use. You
>> talk as if even a BoF is needed, if yes that's what you should go for.
>>
>> Regards,
>>
>> Behcet
>>
>>> Regards,
>>> Thierry Ernst.
>>>
>>>
>>>> Le 11 janv. 2016 à 17:35, Behcet Sarikaya <sarikaya2...@gmail.com> a
>>>> écrit :
>>>>
>>>> On Sat, Jan 9, 2016 at 5:56 AM, Thierry Ernst <thierry.er...@inria.fr>
>>>> wrote:
>>>>>
>>>>>
>>>>> What are protocols you think no one uses ?
>>>>>
>>>>> MIPv6 and NEMOv6 needs maintenance, and probably more than than
>>>>> maintenance.
>>>>>
>>>>
>>>> Thierry, I meant PMIPv6 which was designed for operator networks.
>>>>
>>>> For MIPv6/NEMOv6, I think in Europe, some research based use is
>>>> happening, to my knowledge at a very small scale.
>>>> mip6 WG has been closed long time ago.
>>>> I wish it were still open, that would be like in good old days.
>>>>
>>>> So conference papers and ISE is still my recipe.
>>>>
>>>> Regards,
>>>>
>>>> Behcet
>>>>>
>>>>> Regards,
>>>>> Thierry Ernst.
>>>>>
>>>>>
>>>>>> Le 8 janv. 2016 à 20:48, Behcet Sarikaya <sarikaya2...@gmail.com> a
>>>>>> écrit :
>>>>>>
>>>>>> On Fri, Jan 8, 2016 at 12:34 PM, Jouni.nosmap <jouni.nos...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Well one can always pursue ISE/AD sponsored track if one so feels
>>>>>>> like.
>>>>>>>
>>>>>>> Just saying there are options..  if one desires to go through the WG
>>>>>>> process DMM has provisions for Mobile IPv6 protocol family maintenance 
>>>>>>> work.
>>>>>>>
>>>>>>
>>>>>> I started this thread by stating that:
>>>>>>
>>>>>> Let me ask what is the point in maintaining the protocols that no one
>>>>>> uses?
>>>>>> For academic purposes? If yes, then they should find their places in
>>>>>> the conferences or journals.
>>>>>>
>>>>>> No one objected to the first point.
>>>>>>
>>>>>> So what is the justification for maintenance? As I said before,
>>>>>> charter items can be changed or they do not have to be used.
>>>>>>
>>>>>> Behcet
>>>>>>>
>>>>>>> Jouni
>>>>>>>
>>>>>>> Sent from a smart phone.. Mind the typos..
>>>>>>>
>>>>>>>> Behcet Sarikaya <sari

Re: [DMM] conclusion of adoption calls

[Behcet Sarikaya]

On Mon, Jan 11, 2016 at 11:23 AM, Thierry Ernst <thierry.er...@inria.fr> wrote:
>
> The purpose of conference papers is to do research, so I don’t see how 
> conferences papers would help to do … maintenance of IETF RFCs. In addition 
> to bug fixes, MIPv6 and NEMO need to be progressed in the IETF hierarchy of 
> standards. There are issues and options to be discussed, probably even 
> extensions; a WG must host such work. My take is that dmm is the right 
> candidate WG for this to happen.
>

I still don't see any statements from you on the real need or use. You
talk as if even a BoF is needed, if yes that's what you should go for.

Regards,

Behcet

> Regards,
> Thierry Ernst.
>
>
>> Le 11 janv. 2016 à 17:35, Behcet Sarikaya <sarikaya2...@gmail.com> a écrit :
>>
>> On Sat, Jan 9, 2016 at 5:56 AM, Thierry Ernst <thierry.er...@inria.fr> wrote:
>>>
>>> What are protocols you think no one uses ?
>>>
>>> MIPv6 and NEMOv6 needs maintenance, and probably more than than maintenance.
>>>
>>
>> Thierry, I meant PMIPv6 which was designed for operator networks.
>>
>> For MIPv6/NEMOv6, I think in Europe, some research based use is
>> happening, to my knowledge at a very small scale.
>> mip6 WG has been closed long time ago.
>> I wish it were still open, that would be like in good old days.
>>
>> So conference papers and ISE is still my recipe.
>>
>> Regards,
>>
>> Behcet
>>> Regards,
>>> Thierry Ernst.
>>>
>>>
>>>> Le 8 janv. 2016 à 20:48, Behcet Sarikaya <sarikaya2...@gmail.com> a écrit :
>>>>
>>>> On Fri, Jan 8, 2016 at 12:34 PM, Jouni.nosmap <jouni.nos...@gmail.com> 
>>>> wrote:
>>>>> Well one can always pursue ISE/AD sponsored track if one so feels like.
>>>>>
>>>>> Just saying there are options..  if one desires to go through the WG 
>>>>> process DMM has provisions for Mobile IPv6 protocol family maintenance 
>>>>> work.
>>>>>
>>>>
>>>> I started this thread by stating that:
>>>>
>>>> Let me ask what is the point in maintaining the protocols that no one uses?
>>>> For academic purposes? If yes, then they should find their places in
>>>> the conferences or journals.
>>>>
>>>> No one objected to the first point.
>>>>
>>>> So what is the justification for maintenance? As I said before,
>>>> charter items can be changed or they do not have to be used.
>>>>
>>>> Behcet
>>>>> Jouni
>>>>>
>>>>> Sent from a smart phone.. Mind the typos..
>>>>>
>>>>>> Behcet Sarikaya <sarikaya2...@gmail.com> kirjoitti 8.1.2016 kello 9.15:
>>>>>>
>>>>>>> On Fri, Jan 8, 2016 at 10:39 AM, Jouni Korhonen 
>>>>>>> <jouni.nos...@gmail.com> wrote:
>>>>>>>
>>>>>>> As Sri pointed out DMM is OK to work on "maintenance-oriented 
>>>>>>> extensions of
>>>>>>> the Mobile IPv6 protocol family". So this is likely the venue within 
>>>>>>> IETF.
>>>>>>> Mobile IPv4 as such has no place here.
>>>>>>
>>>>>>
>>>>>> Why not ISE? For both MIPv6 and MIPv4.
>>>>>> Of course you may not be able modify existing RFCs but just write it
>>>>>> as a new draft and do not bother dmm where future protocol work is
>>>>>> supposed to be done.
>>>>>>
>>>>>> Behcet
>>>>>>
>>>>>>> - Jouni
>>>>>>>
>>>>>>>
>>>>>>> 1/8/2016, 6:50 AM, Thierry Ernst kirjoitti:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Alex, all,
>>>>>>>>
>>>>>>>> My understanding of what Jouni wrote is that it’s fine to work on MIP6
>>>>>>>> improvement, but the MIP4 can live its life as is, to which I totally 
>>>>>>>> agree.
>>>>>>>> And I also agree with Alex that we need to fix bugs in MIP6 (and the 
>>>>>>>> related
>>>>>>>> suite, in particular NEMO) and progress them in the standard track. It 
>>>>>>>> has
>>>>>>>> been too long since we last work on those and now it is 

Re: [DMM] conclusion of adoption calls

[Behcet Sarikaya]

On Fri, Jan 8, 2016 at 12:34 PM, Jouni.nosmap <jouni.nos...@gmail.com> wrote:
> Well one can always pursue ISE/AD sponsored track if one so feels like.
>
> Just saying there are options..  if one desires to go through the WG process 
> DMM has provisions for Mobile IPv6 protocol family maintenance work.
>

I started this thread by stating that:

Let me ask what is the point in maintaining the protocols that no one uses?
For academic purposes? If yes, then they should find their places in
the conferences or journals.

No one objected to the first point.

So what is the justification for maintenance? As I said before,
charter items can be changed or they do not have to be used.

Behcet
> Jouni
>
> Sent from a smart phone.. Mind the typos..
>
>> Behcet Sarikaya <sarikaya2...@gmail.com> kirjoitti 8.1.2016 kello 9.15:
>>
>>> On Fri, Jan 8, 2016 at 10:39 AM, Jouni Korhonen <jouni.nos...@gmail.com> 
>>> wrote:
>>>
>>> As Sri pointed out DMM is OK to work on "maintenance-oriented extensions of
>>> the Mobile IPv6 protocol family". So this is likely the venue within IETF.
>>> Mobile IPv4 as such has no place here.
>>
>>
>> Why not ISE? For both MIPv6 and MIPv4.
>> Of course you may not be able modify existing RFCs but just write it
>> as a new draft and do not bother dmm where future protocol work is
>> supposed to be done.
>>
>> Behcet
>>
>>> - Jouni
>>>
>>>
>>> 1/8/2016, 6:50 AM, Thierry Ernst kirjoitti:
>>>>
>>>>
>>>> Hi Alex, all,
>>>>
>>>> My understanding of what Jouni wrote is that it’s fine to work on MIP6
>>>> improvement, but the MIP4 can live its life as is, to which I totally 
>>>> agree.
>>>> And I also agree with Alex that we need to fix bugs in MIP6 (and the 
>>>> related
>>>> suite, in particular NEMO) and progress them in the standard track. It has
>>>> been too long since we last work on those and now it is certainly right to
>>>> do it.
>>>>
>>>> So, the question is if DMM is the right place or not to do the work, if
>>>> not I would like to hear about alternatives within the IETF.
>>>>
>>>> Regards,
>>>> Thierry.
>>>>
>>>>
>>>>
>>>>> Le 8 janv. 2016 à 13:54, Alexandre Petrescu
>>>>> <alexandre.petre...@gmail.com> a écrit :
>>>>>
>>>>>
>>>>>
>>>>> Le 22/12/2015 04:56, Jouni a écrit :
>>>>>>
>>>>>>
>>>>>> Behcet,
>>>>>>
>>>>>> Thank you for your constructive comments. I believe academic
>>>>>> conferences/journals are not appropriate venues for PMIPv6/MIPv6
>>>>>> maintenance since these protocol families are already past their
>>>>>> prime time as “hot research topics". Looking at the existing charter
>>>>>> I cannot find too much love towards anything IPv4 so I think we can
>>>>>> let MIPv4 finally rest in peace.
>>>>>
>>>>>
>>>>> Jouni I can agree with you in general.
>>>>>
>>>>> But let me suggest that MIPv4 and MIPv6 are two implementations very
>>>>> important in some places including where I work.
>>>>>
>>>>> They are no longer 'hot' as you say, but there are certainly protocol and
>>>>> implementation bugs which need correction.  Actually some of the 
>>>>> corrections
>>>>> have already been applied but are not reflected in RFCs.
>>>>>
>>>>> Sometimes there is a feeling of frustration if implementations thrive
>>>>> where WG cares little.
>>>>>
>>>>>  a widespread implementation of MIP6 is still bugged and
>>>>> does not respect the MIPv6 RFC - do you want that discussed
>>>>> publicly?.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> - Jouni
>>>>>>
>>>>>>
>>>>>>> On 21 Dec 2015, at 09:46, Behcet Sarikaya <sarikaya2...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Jouni, all,
>>>>>>>
>>>>>>> Let me ask what is the point in maintaining the protocols that no
>>>>>>> one uses? For academic purposes? If yes, then they should find
>

Re: [DMM] conclusion of adoption calls

[Behcet Sarikaya]

On Fri, Jan 8, 2016 at 10:39 AM, Jouni Korhonen <jouni.nos...@gmail.com> wrote:
>
> As Sri pointed out DMM is OK to work on "maintenance-oriented extensions of
> the Mobile IPv6 protocol family". So this is likely the venue within IETF.
> Mobile IPv4 as such has no place here.
>


Why not ISE? For both MIPv6 and MIPv4.
Of course you may not be able modify existing RFCs but just write it
as a new draft and do not bother dmm where future protocol work is
supposed to be done.

Behcet

> - Jouni
>
>
> 1/8/2016, 6:50 AM, Thierry Ernst kirjoitti:
>>
>>
>> Hi Alex, all,
>>
>> My understanding of what Jouni wrote is that it’s fine to work on MIP6
>> improvement, but the MIP4 can live its life as is, to which I totally agree.
>> And I also agree with Alex that we need to fix bugs in MIP6 (and the related
>> suite, in particular NEMO) and progress them in the standard track. It has
>> been too long since we last work on those and now it is certainly right to
>> do it.
>>
>> So, the question is if DMM is the right place or not to do the work, if
>> not I would like to hear about alternatives within the IETF.
>>
>> Regards,
>> Thierry.
>>
>>
>>
>>> Le 8 janv. 2016 à 13:54, Alexandre Petrescu
>>> <alexandre.petre...@gmail.com> a écrit :
>>>
>>>
>>>
>>> Le 22/12/2015 04:56, Jouni a écrit :
>>>>
>>>>
>>>> Behcet,
>>>>
>>>> Thank you for your constructive comments. I believe academic
>>>> conferences/journals are not appropriate venues for PMIPv6/MIPv6
>>>> maintenance since these protocol families are already past their
>>>> prime time as “hot research topics". Looking at the existing charter
>>>> I cannot find too much love towards anything IPv4 so I think we can
>>>> let MIPv4 finally rest in peace.
>>>
>>>
>>> Jouni I can agree with you in general.
>>>
>>> But let me suggest that MIPv4 and MIPv6 are two implementations very
>>> important in some places including where I work.
>>>
>>> They are no longer 'hot' as you say, but there are certainly protocol and
>>> implementation bugs which need correction.  Actually some of the corrections
>>> have already been applied but are not reflected in RFCs.
>>>
>>> Sometimes there is a feeling of frustration if implementations thrive
>>> where WG cares little.
>>>
>>>  a widespread implementation of MIP6 is still bugged and
>>> does not respect the MIPv6 RFC - do you want that discussed
>>> publicly?.
>>>
>>> Alex
>>>
>>>>
>>>> - Jouni
>>>>
>>>>
>>>>> On 21 Dec 2015, at 09:46, Behcet Sarikaya <sarikaya2...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi Jouni, all,
>>>>>
>>>>> Let me ask what is the point in maintaining the protocols that no
>>>>> one uses? For academic purposes? If yes, then they should find
>>>>> their places in the conferences or journals.
>>>>>
>>>>> Now, mip4 WG has been closed. So is dmm going to maintain mip4 as
>>>>> well?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Behcet
>>>>>
>>>>> On Fri, Dec 18, 2015 at 5:45 AM, Carlos Jesús Bernardos Cano
>>>>> <c...@it.uc3m.es> wrote:
>>>>>>
>>>>>> Hi Jouni, all,
>>>>>>
>>>>>> Although I'm already late, I just wanted to express my
>>>>>> post-adoption call to the three drafts.
>>>>>>
>>>>>> Carlos
>>>>>>
>>>>>> On Wed, 2015-12-16 at 08:32 -0800, Jouni Korhonen wrote:
>>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> The WG adoption call for all three I-Ds have completed:
>>>>>>> draft-gundavelli-dmm-lma-controlled-mag-params-00
>>>>>>> draft-yan-dmm-hnprenum-03 draft-seite-dmm-rg-multihoming-02
>>>>>>>
>>>>>>> The adoption for the first two was unanimous. The last
>>>>>>> (draft-seita- *) received few concerns but the number of
>>>>>>> supporters was enough to convince the chairs there is enough
>>>>>>> interest and support to work on it. The chairs encourage the
>>>>>>> authors of draft-seite-* to pay close attention and work out
>>>>>>> the concerns raised during the adoption call.
>>>>>>>
>>>>>>> For the I-D authors. Please, submit draft-ietf-*-00 versions of
>>>>>>> the documents as soon as possible.
>>>>>>>
>>>>>>> - Jouni & Dapeng
>>>>>>>
>>>>>>> ___ dmm mailing
>>>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>>>>>>
>>>>>>
>>>>>> ___ dmm mailing list
>>>>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>>
>>>> ___ dmm mailing list
>>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>
>>> ___
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] conclusion of adoption calls

[Behcet Sarikaya]

Hi Jouni,


On Mon, Dec 21, 2015 at 9:56 PM, Jouni <jouni.nos...@gmail.com> wrote:
>
> Behcet,
>
> Thank you for your constructive comments. I believe academic 
> conferences/journals are not appropriate venues for PMIPv6/MIPv6 maintenance 
> since these protocol families are already past their prime time as “hot 
> research topics".

Are you second guessing conference/journal decision people? Again,
with my academic background I can say that we should stay away from
such things.

Another implication of what you seem to be saying is that these poor
guys can not publish in conferences/journals, dmm should give them a
refuge?

Of course ISE could be a channel, just say go to ISE.

> Looking at the existing charter

As you know charters can be modified. Especially charter items are
easy to be modified, i.e. probably no need to go to IESG. I have seen
chairs modifying charter items, with AD approval.

> I cannot find too much love towards anything IPv4 so I think we can let MIPv4 
> finally rest in peace.

Maybe that's your thinking, other people may have different opinion.

Behcet
>
> - Jouni
>
>
>> On 21 Dec 2015, at 09:46, Behcet Sarikaya <sarikaya2...@gmail.com> wrote:
>>
>> Hi Jouni, all,
>>
>> Let me ask what is the point in maintaining the protocols that no one uses?
>> For academic purposes? If yes, then they should find their places in
>> the conferences or journals.
>>
>> Now, mip4 WG has been closed. So is dmm going to maintain mip4 as well?
>>
>> Regards,
>>
>> Behcet
>>
>> On Fri, Dec 18, 2015 at 5:45 AM, Carlos Jesús Bernardos Cano
>> <c...@it.uc3m.es> wrote:
>>> Hi Jouni, all,
>>>
>>> Although I'm already late, I just wanted to express my post-adoption
>>> call to the three drafts.
>>>
>>> Carlos
>>>
>>> On Wed, 2015-12-16 at 08:32 -0800, Jouni Korhonen wrote:
>>>> Folks,
>>>>
>>>> The WG adoption call for all three I-Ds have completed:
>>>>  draft-gundavelli-dmm-lma-controlled-mag-params-00
>>>>  draft-yan-dmm-hnprenum-03
>>>>  draft-seite-dmm-rg-multihoming-02
>>>>
>>>> The adoption for the first two was unanimous. The last (draft-seita-
>>>> *)
>>>> received few concerns but the number of supporters was enough to
>>>> convince the chairs there is enough interest and support to work on
>>>> it.
>>>> The chairs encourage the authors of draft-seite-* to pay close
>>>> attention
>>>> and work out the concerns raised during the adoption call.
>>>>
>>>> For the I-D authors. Please, submit draft-ietf-*-00 versions of the
>>>> documents as soon as possible.
>>>>
>>>> - Jouni & Dapeng
>>>>
>>>> ___
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>> ___
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] conclusion of adoption calls

[Behcet Sarikaya]

On Mon, Dec 21, 2015 at 3:56 PM, Sri Gundavelli (sgundave)
<sgund...@cisco.com> wrote:
> Beat the protocol any time things don¹t go our way.
>
>
> Published September 14, 2015
>
>
> https://www.ietf.org/id/draft-sarikaya-nvo3-vmm-dmm-pmip-07.txt
>

Have you read that draft? Here is the abstract:

This document specifies a virtual machine mobility protocol in data
   centers built with overlay-based network virtualization approach.
   The protocol is based on using NVA-NVE protocol to update ARP table
   or neighbor cache entries at the NVA and the source NVEs tunneling
   in-flight packets to the destination NVE after the virtual machine
   moves from source NVE to the destination NVE.

It has nothing to do with PMIP, we just forgot to change the draft title.
In any case the draft was not submitted as a maintenance draft to dmm.


> I wonder why ? Academic interest ?
>

As you may know I was professor for many years. So I know what
academic interest means.

Behcet
>
>
>
> On 12/21/15, 9:46 AM, "dmm on behalf of Behcet Sarikaya"
> <dmm-boun...@ietf.org on behalf of sarikaya2...@gmail.com> wrote:
>
>>
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] conclusion of adoption calls

[Behcet Sarikaya]

Hi Jouni, all,

Let me ask what is the point in maintaining the protocols that no one uses?
For academic purposes? If yes, then they should find their places in
the conferences or journals.

Now, mip4 WG has been closed. So is dmm going to maintain mip4 as well?

Regards,

Behcet

On Fri, Dec 18, 2015 at 5:45 AM, Carlos Jesús Bernardos Cano
 wrote:
> Hi Jouni, all,
>
> Although I'm already late, I just wanted to express my post-adoption
> call to the three drafts.
>
> Carlos
>
> On Wed, 2015-12-16 at 08:32 -0800, Jouni Korhonen wrote:
>> Folks,
>>
>> The WG adoption call for all three I-Ds have completed:
>>   draft-gundavelli-dmm-lma-controlled-mag-params-00
>>   draft-yan-dmm-hnprenum-03
>>   draft-seite-dmm-rg-multihoming-02
>>
>> The adoption for the first two was unanimous. The last (draft-seita-
>> *)
>> received few concerns but the number of supporters was enough to
>> convince the chairs there is enough interest and support to work on
>> it.
>> The chairs encourage the authors of draft-seite-* to pay close
>> attention
>> and work out the concerns raised during the adoption call.
>>
>> For the I-D authors. Please, submit draft-ietf-*-00 versions of the
>> documents as soon as possible.
>>
>> - Jouni & Dapeng
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

[Behcet Sarikaya]

Hi Pierrick,

I hope you know how to read.
 I said noone so far said SGW should be multihomed, i.e. it should
send some of its traffic to fixed network.

In fact multihomed is wrong here as it is used for the hosts while we
are talking here about SGW or RG which have LAN and WAN side
interfaces.

I believe this draft is not ready for adoption.

Regards,

Behcet

On Wed, Dec 2, 2015 at 2:21 AM,  <pierrick.se...@orange.com> wrote:
> Hi Behcet,
>
> This extension is for any use-case requiring a MAG to be multihomed. For 
> sure,  multihomed RG can be one of them, but there is no reason to restrict 
> MCoA to this use-case.
>
> Pierrick
>
>> -Message d'origine-
>> De : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya
>> Envoyé : mardi 1 décembre 2015 18:18
>> À : Jong-Hyouk Lee
>> Cc : dmm
>> Objet : Re: [DMM] Call for adoption confirmation: 
>> draft-seite-dmm-rg-multihoming-
>> 02
>>
>> Hi Jong-Hyouk,
>>
>> On Mon, Nov 30, 2015 at 10:34 AM, Jong-Hyouk Lee <jonghy...@gmail.com>
>> wrote:
>> > Hi all
>> >
>> > I support the adoption of this draft as a WG draft even with the
>> > concerns pointed by Mingui. This draft has a merit of the introduction
>> > of the generic protocol extension allowing a multihomed MAG
>>
>> No, the extension is for the RG, i.e. Residential Gateway which is a 
>> broadband or
>> fixed network element.
>>
>>
>> > to register more than one PCoA
>> > to the LMA. It is definitely useful for a multihomed environment.
>>
>> Why would a MAG be multihomed? I am not aware of any proposals that e..g  the
>> serving gateway in 3GPP network where MAG is placed should be multihomed.
>>
>>
>> Regards,
>> Behcet
>> >  Authors
>> > may update this draft to address Mingui’s comments if needed.
>> >
>> > J.
>> > --
>> > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
>> > Protocol Engineering Lab., Sangmyung University
>> >
>> > #email: jonghy...@gmail.com
>> > #webpage: https://sites.google.com/site/hurryon
>> >
>> > On Nov 26, 2015, at 5:00 PM, Mingui Zhang <zhangmin...@huawei.com> wrote:
>> >
>> > Hi,
>> >
>> > I remember it was suggested to remove DSL, “Hybrid Access”, etc, and
>> > the suggestion was acknowledged. We haven’t seen an updated version
>> > yet. It is not ready to be adopted, I think.
>> >
>> > I have read the draft. I found the scope greatly shrinked from the 01 to 
>> > 02.
>> > I guess the draft wants to fight through by providing a more generic
>> > protocol extension, while awaiting for real use cases. And, Hybrid
>> > Access could be treated as a potential use case (Actually, the DSL+LTE
>> > scenario is now intentionally inherited from the 00 version as a use
>> > case.).  If I guess right, I don’t think it’s a good starting point
>> > since it only covers a fragment of a possible solution. Besides the
>> > care of addresses, there are many other gaps that have not been
>> > touched: per-packet traffic classification and recombination,
>> > performance measurement, the bypass requirement, etc. From the draft,
>> > we cannot figure out a clear architectural overview. Section 3 doesn’t 
>> > help much.
>> >
>> > Hence, I oppose its adoption.
>> >
>> > Thanks,
>> > Mingui
>> >
>> > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dapeng Liu
>> > Sent: Thursday, November 26, 2015 12:22 AM
>> > To: dmm
>> > Subject: [DMM] Call for adoption confirmation:
>> > draft-seite-dmm-rg-multihoming-02
>> >
>> > Hello all,
>> >
>> > In IETF94, we initiated the call for adoption for the draft:
>> > draft-seite-dmm-rg-multihoming-02:
>> > http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02
>> > Seems have got sufficient support during the meeting. We'd like to
>> > confirm the call for adoption in the mailing list for 2 weeks.
>> > Please send your opinion and comments to the list before December 9.
>> >
>> >
>> > Thanks,
>> > --
>> > Best Regards,
>> > Dapeng
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > --
>> > Best Regards,
>> > Dapeng Liu
>> > ___
>> > dmm mailing list
>> > dmm@ietf.org
>> > ht

Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

[Behcet Sarikaya]

Hi Jouni,


On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen  wrote:
> As an individual contributor I support the adoption of this I-D. MCoA is a
> feature that we still lack..
>

Are you sure?

MCoA is solved in Netext Flow Mobility draft,

draft-ietf-netext-pmipv6-flowmob-14

is the latest draft.

BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The
chair asked only those who accept. The chair unfortunately did not ask
those who oppose.

As you know, if the chair wishes to ask a single question then the
right one is any opposes.

Regards,

Behcet
> The document itself still needs quite a bit of work. For example, I wonder
> if the caption for Figure 2 is correct. Also, Section 4.1. option fiels
> descriptions are somewhat broken it seems. And so on multiple small nits
> like unexpanded acronyms etc. However, these are mainly editorials. I have
> no problem with the technical solution.
>
> - Jouni
>
>
>
> 11/25/2015, 8:22 AM, Dapeng Liu kirjoitti:
>>
>> Hello all,
>>
>> In IETF94, we initiated the call for adoption for the draft:
>> draft-seite-dmm-rg-multihoming-02
>> :
>> http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02
>> Seems have got sufficient support during the meeting. We'd like to
>> confirm the call for adoption in the mailing list for 2 weeks.
>> Please send your opinion and comments to the list before December 9.
>>
>>
>> Thanks,
>> --
>> Best Regards,
>> Dapeng
>>
>>
>>
>>
>>
>> --
>>
>> --
>> Best Regards,
>> Dapeng Liu
>>
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

[Behcet Sarikaya]

Hi Jong-Hyouk,

On Mon, Nov 30, 2015 at 10:34 AM, Jong-Hyouk Lee  wrote:
> Hi all
>
> I support the adoption of this draft as a WG draft even with the concerns
> pointed by Mingui. This draft has a merit of the introduction of the generic
> protocol extension allowing a multihomed MAG

No, the extension is for the RG, i.e. Residential Gateway which is a
broadband or fixed network element.


> to register more than one PCoA
> to the LMA. It is definitely useful for a multihomed environment.

Why would a MAG be multihomed? I am not aware of any proposals that
e..g  the serving gateway in 3GPP network where MAG is placed should
be multihomed.


Regards,
Behcet
>  Authors
> may update this draft to address Mingui’s comments if needed.
>
> J.
> --
> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
> Protocol Engineering Lab., Sangmyung University
>
> #email: jonghy...@gmail.com
> #webpage: https://sites.google.com/site/hurryon
>
> On Nov 26, 2015, at 5:00 PM, Mingui Zhang  wrote:
>
> Hi,
>
> I remember it was suggested to remove DSL, “Hybrid Access”, etc, and the
> suggestion was acknowledged. We haven’t seen an updated version yet. It is
> not ready to be adopted, I think.
>
> I have read the draft. I found the scope greatly shrinked from the 01 to 02.
> I guess the draft wants to fight through by providing a more generic
> protocol extension, while awaiting for real use cases. And, Hybrid Access
> could be treated as a potential use case (Actually, the DSL+LTE scenario is
> now intentionally inherited from the 00 version as a use case.).  If I guess
> right, I don’t think it’s a good starting point since it only covers a
> fragment of a possible solution. Besides the care of addresses, there are
> many other gaps that have not been touched: per-packet traffic
> classification and recombination, performance measurement, the bypass
> requirement, etc. From the draft, we cannot figure out a clear architectural
> overview. Section 3 doesn’t help much.
>
> Hence, I oppose its adoption.
>
> Thanks,
> Mingui
>
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dapeng Liu
> Sent: Thursday, November 26, 2015 12:22 AM
> To: dmm
> Subject: [DMM] Call for adoption confirmation:
> draft-seite-dmm-rg-multihoming-02
>
> Hello all,
>
> In IETF94, we initiated the call for adoption for the draft:
> draft-seite-dmm-rg-multihoming-02:
> http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02
> Seems have got sufficient support during the meeting. We'd like to confirm
> the call for adoption in the mailing list for 2 weeks.
> Please send your opinion and comments to the list before December 9.
>
>
> Thanks,
> --
> Best Regards,
> Dapeng
>
>
>
>
>
> --
>
> --
> Best Regards,
> Dapeng Liu
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] vepc draft Rev. 04

[Behcet Sarikaya]

 Hi Matsushima-san,

On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
 Hi Behcet-san,

 On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya sarikaya2...@gmail.com
 wrote:

 Hi Satoru,

 Thanks for your reply.

 Let me continue the discussion with your text in Section 3.2 where you
 mention
 vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
 that defines FPCP Agent function and Client function.

 I don't understand how you could justify defining a new forwarding
 policy configuration protocol to do this Agent/Client functionality?
 Why not use similar Agent/Client models that are being defined rather
 than defining a new protocol?
 I think this point requires much stronger justification which I could
 not see in Section 3.2.


 The text just describes about a part of where FPCP may be applicable in
 vEPC.




 Are you that we have to to reinvent the wheel, rather than reusing
 something that is already available? How are we going to reinvent that
 wheel also remains to be seen, I think.


 Point taken. Which kind of wheel do you have in mind?

 Please check this draft:
https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-02

Regards,

Behcet

 cheers,
 --satoru


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] vepc draft Rev. 04

[Behcet Sarikaya]

Hi Satoru,

Thanks for your reply.

Let me continue the discussion with your text in Section 3.2 where you mention
vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
that defines FPCP Agent function and Client function.

I don't understand how you could justify defining a new forwarding
policy configuration protocol to do this Agent/Client functionality?
Why not use similar Agent/Client models that are being defined rather
than defining a new protocol?
I think this point requires much stronger justification which I could
not see in Section 3.2.

Are you that we have to to reinvent the wheel, rather than reusing
something that is already available? How are we going to reinvent that
wheel also remains to be seen, I think.

Regards,

Behcet



On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
 Hi Bechet-san,

 Thank you for your question.
 In step (15), I meant that EPC-E advertises prefix including UE assigned
 prefixes.

 For example, in the case of /64 prefixes assigned to UEs from a /56 space,
 that /56
 is advertised by EPC-E to upstream routers. So the advertised route isn't
 host routes.

 Depends on configuration policy, but one case is that the source of that
 advertised
 /56 route might be statically configured in EPC-E.

 Regards,
 --satoru



 On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com
 wrote:

  Hi Matsushima-san,

 I have a question on your draft:
 In Sec. 3.2, page 11, you say
 In step (15), the EPC-E advertises routes to upstream routers ...

 Are these routes static/host routes?

 Regards,

 Behcet



___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] vepc draft Rev. 04

[Behcet Sarikaya]

 Hi Matsushima-san,

I have a question on your draft:
In Sec. 3.2, page 11, you say
In step (15), the EPC-E advertises routes to upstream routers ...

Are these routes static/host routes?

Regards,

Behcet

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01

[Behcet Sarikaya]

I am still not convinced.
At home I have LTE.
LTE can be 3G if it is somewhat degraded and 3G is also available, so
no reason for inter technology handoff.

I am also concerned on some other MN ids proposed like RFid, what is
the assumption there? Is it that the sensor node will have Mobile IP
client?
To that I say, give me a break.

Behcet
Behcet

On Fri, Apr 24, 2015 at 3:27 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
 Le 23/04/2015 19:11, Behcet Sarikaya a écrit :

 On Wed, Apr 22, 2015 at 11:45 AM, Alexandru Petrescu
 alexandru.petre...@gmail.com wrote:

 Le 22/04/2015 18:06, Behcet Sarikaya a écrit :


Hi Alex,

 On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu
 alexandru.petre...@gmail.com wrote:


 Le 16/04/2015 06:58, Jouni Korhonen a écrit :



 Folks,

 The adoption call for this I-D has ended. There is a clear concensus
 to
 adopt the I-D as a working group item.




 I support its adoption.

 We have been working with an identifier specific to automobiles to use
 to
 realize access control.  Identifying an entire set of IP nodes deployed
 in a
 vehicle is different than identifying an end-user like address@realm.

 We looked for such an identifier and believe the VIN (Vehicle
 Identification
 Number) be a good candidate.

 One would consider using one type, like type 40, to encode the VIN or
 parts
 of it, into an MN-ID.

 The questions to the group are the following:
 - is VIN considered private information? (in deployments it is private
 to a certain extent, but publicly avaliable to cameras or in public
 databases to another extent).
 - is the MN-ID type 40 ok for it.
 - is one type sufficient or should there be subtypes.



 What is your model here in providing Internet access to the car?
 As you may know, operators in US are deploying systems that connect
 the car to their LTE network upstream and downstream is the passengers
 in the car that access over Wi-Fi.
 With LTE, you get mobility support which is based on fixed anchoring.
 I cc'ed to Raj who works on these types of technologies.
 The ID there is the IMSI. I don't think vin is used.



 The model of Internet access to the cars for cars currently on market in
 Europe is the same - the LTE technology is used, using the IMSI as an
 identifier.  However, that does not use MN-ID, is only IPv4, is not WiFi
 and
 does not resist to cellular generation upgrades to 5G and beyond.


 I don't understand the handover scenario. I think you are mixing the
 car and the passengers in the car.
 LTE is available on a large geography, why should you handover the
 upstream traffic to Wi-Fi?


 When the car arrives home it connects to the WiFi available in home, thus
 handing over from LTE.  This is a sold use-case at e.g. Tesla.  The WiFi
 hotspot can be the one deployed in-house, in-garage, or the WiFi offered by
 the electrical recharging stations.

 Other manufacturers propose scenarios in which car's WiFi antenna switches
 from being an in-car hotspot to being a Client to outside wifi.

 Some consider 802.11p (wifi for vehicles) to be deployed along highways and
 cars to perform handovers between these 802.11p access points.

 Next time on highway scan for WiFi - one is surprised by the number of
 hotspots driving around, even though often they use portals.

 There are many commercially considered scenarios involving WiFi handovers
 for cars.

 Alex



 Behcet


 Newer models will feature IPv6 in addition to IPv4, WiFi handover from
 LTE
 to house's hotspot, continuous sessions, and over-the-air software update
 for cheap upgradeability to future generation 5G and beyond.

 In this context it is hard to imagine IMSI will be there for a long time
 in
 a given car, and a more permanent identifier is needed.

 To Raj - is LTE considering other kinds of identifiers for access control
 (other than IMSI) for vehicular environments, like V2X?

 Alex




 Regards,

 Behcet



 Yours,

 Alex



 - Jouni  Dapeng

 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti:



 Folks,

 This emails starts a two week call for the I-D
  draft-perkins-dmm-4283mnids-01
 to confirm the aadoption s a DMM WG document. The call ends April
 15th
 EOB PST.

 Express your support or opposition to the mailing list. During the
 IETF92 meeting we got 7 voices for the adoption so at least the same
 amount supporting emails should be expected.

 - Jouni  Dapeng




 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm




 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm











___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01

[Behcet Sarikaya]

On Fri, Apr 24, 2015 at 3:27 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
 Le 23/04/2015 19:11, Behcet Sarikaya a écrit :

 On Wed, Apr 22, 2015 at 11:45 AM, Alexandru Petrescu
 alexandru.petre...@gmail.com wrote:

 Le 22/04/2015 18:06, Behcet Sarikaya a écrit :


Hi Alex,

 On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu
 alexandru.petre...@gmail.com wrote:


 Le 16/04/2015 06:58, Jouni Korhonen a écrit :



 Folks,

 The adoption call for this I-D has ended. There is a clear concensus
 to
 adopt the I-D as a working group item.




 I support its adoption.

 We have been working with an identifier specific to automobiles to use
 to
 realize access control.  Identifying an entire set of IP nodes deployed
 in a
 vehicle is different than identifying an end-user like address@realm.

 We looked for such an identifier and believe the VIN (Vehicle
 Identification
 Number) be a good candidate.

 One would consider using one type, like type 40, to encode the VIN or
 parts
 of it, into an MN-ID.

 The questions to the group are the following:
 - is VIN considered private information? (in deployments it is private
 to a certain extent, but publicly avaliable to cameras or in public
 databases to another extent).
 - is the MN-ID type 40 ok for it.
 - is one type sufficient or should there be subtypes.



 What is your model here in providing Internet access to the car?
 As you may know, operators in US are deploying systems that connect
 the car to their LTE network upstream and downstream is the passengers
 in the car that access over Wi-Fi.
 With LTE, you get mobility support which is based on fixed anchoring.
 I cc'ed to Raj who works on these types of technologies.
 The ID there is the IMSI. I don't think vin is used.



 The model of Internet access to the cars for cars currently on market in
 Europe is the same - the LTE technology is used, using the IMSI as an
 identifier.  However, that does not use MN-ID, is only IPv4, is not WiFi
 and
 does not resist to cellular generation upgrades to 5G and beyond.


 I don't understand the handover scenario. I think you are mixing the
 car and the passengers in the car.
 LTE is available on a large geography, why should you handover the
 upstream traffic to Wi-Fi?


 When the car arrives home it connects to the WiFi available in home, thus
 handing over from LTE.  This is a sold use-case at e.g. Tesla.  The WiFi
 hotspot can be the one deployed in-house, in-garage, or the WiFi offered by
 the electrical recharging stations.



Even if the is the case then 3GPP developed a lot of things on
accessing non-3GPP networks like Wi-Fi. I think line-id is used
instead of IMSI?

Behcet
 Other manufacturers propose scenarios in which car's WiFi antenna switches
 from being an in-car hotspot to being a Client to outside wifi.

 Some consider 802.11p (wifi for vehicles) to be deployed along highways and
 cars to perform handovers between these 802.11p access points.

 Next time on highway scan for WiFi - one is surprised by the number of
 hotspots driving around, even though often they use portals.

 There are many commercially considered scenarios involving WiFi handovers
 for cars.

 Alex



 Behcet


 Newer models will feature IPv6 in addition to IPv4, WiFi handover from
 LTE
 to house's hotspot, continuous sessions, and over-the-air software update
 for cheap upgradeability to future generation 5G and beyond.

 In this context it is hard to imagine IMSI will be there for a long time
 in
 a given car, and a more permanent identifier is needed.

 To Raj - is LTE considering other kinds of identifiers for access control
 (other than IMSI) for vehicular environments, like V2X?

 Alex




 Regards,

 Behcet



 Yours,

 Alex



 - Jouni  Dapeng

 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti:



 Folks,

 This emails starts a two week call for the I-D
  draft-perkins-dmm-4283mnids-01
 to confirm the aadoption s a DMM WG document. The call ends April
 15th
 EOB PST.

 Express your support or opposition to the mailing list. During the
 IETF92 meeting we got 7 voices for the adoption so at least the same
 amount supporting emails should be expected.

 - Jouni  Dapeng




 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm




 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm











___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00

[Behcet Sarikaya]

On Wed, Apr 15, 2015 at 6:50 PM, Seil Jeon seilj...@av.it.pt wrote:

 This draft is sketched based on a deployment model, which has not been given
 by a draft in the relevant WT. Of course, the main idea and concept were
 presented by Sri in the past meetings. In this case, does the adoption of
 this draft mean that we will go with the deployment model in other WTs?
 Because deployment model affects other WTs' progresses and results. That
 needs to be clearly arranged.


As I said before, having WTs work on pieces of the problem without
agreeing on a base protocol is not the right way to go.

How could a WT improve an aspect without agreeing on what to improve?

FWIW, let me say it again.

Regards,

Behcet

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] offlisted mails - names of Work Teams

[Behcet Sarikaya]

 Hi Alex,

Thank you for raising these points.
 I found the long discussion quite inspiring.

I think that we should not forget that there are many solutions
submitted to dmm. Some are revisions to the integrated solutions like
dmm for wifi, AERO, etc. and some are pieces of solutions like Wei's
address management, Charlie's privacy, etc.

I suggest that in the upcoming dmm session we discuss this issue of solutions.

Regards,

Behcet

On Fri, Oct 24, 2014 at 4:42 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
 I agree with this request from Behcet because it may give greater
 visibility.

 I am interested about what is happening in each of the teams, although I
 also think they need a level of separation from the rest of the world.

 What are the names of the work teams?
 1 - Mobility Exposure
 2 - Forwarding Path and Signalling Management
 3 - Enhanced Anchor

 Is this correct?

 Alex

 Le 23/10/2014 22:03, Behcet Sarikaya a écrit :

   Hi all,

 If you send me an email related to dmm issues and you do not wish the
 mail to be cc'ed or forwarded to the list,
 please MARK your mail clearly on the subject line as offlisted.
 You may wish to send the mail to 20 or so other people, I don't care.

 Otherwise I may inadvertently cc it to the list.

 Let this be known.

 Regards,

 Behcet

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Fwd: DMM's benefits

[Behcet Sarikaya]

 my apologies for forwarding this conversation to this list without
permission from Alper.

Behcet

-- Forwarded message --
From: Behcet Sarikaya sarikaya2...@gmail.com
Date: Thu, Oct 23, 2014 at 10:49 AM
Subject: Re: DMM's benefits
To: Alper Yegin alper.ye...@yegin.org, dmm@ietf.org dmm@ietf.org
Cc: Jouni Korhonen jouni.nos...@gmail.com, Sri Gundavelli
sgund...@cisco.com, karag...@cs.utwente.nl
karag...@cs.utwente.nl, Kostas Pentikousis k.pentikou...@eict.de,
Dapeng Liu liudap...@chinamobile.com, Marco Liebsch
marco.lieb...@neclab.eu, Peter McCann peter.mcc...@huawei.com, h
chan h.anthony.c...@huawei.com, Ryuji Wakikawa
ryuji.wakik...@gmail.com, Zuniga, Juan Carlos
juancarlos.zun...@interdigital.com, Carlos Jesús Bernardos Cano
c...@it.uc3m.es, Suresh Krishnan suresh.krish...@ericsson.com,
pierrick.se...@orange.com IMT/OLN pierrick.se...@orange.com,
Charlie Perkins charlie.perk...@huawei.com, Danny Moses
danny.mo...@intel.com, John Kaippallimalil
john.kaippallima...@huawei.com


 Hi all,

Two observations:
1. I don't understand why this mail was not sent to dmm list? So I added it now.
2. It was amazing to see the amount of speculation made just based on
the acronym DMM (in Alper's mail).

How do we know what DMM solution (let me clarify it a bit) will look
like so we can talk about its performance?

Isn't this what dmm WG should work on first, keeping in mind
performance benefits and other aspects?

Regards,

Behcet

On Wed, Oct 22, 2014 at 2:15 AM, Alper Yegin alper.ye...@yegin.org wrote:
 Guys,

 We've been talking about cost reduction and e2e latency reduction as the 
 benefits of DMM (compared to current architectures).
 Can you point to any measurements, analysis, simulation, data to back that up?

 I remember Dapeng's analysis from earlier meetings. Do you have anything else 
 handy?
 I need to compile additional evidence ...

 Alper


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WG Review: Distributed Mobility Management (dmm)

[Behcet Sarikaya]

 One more comment before the deadline expires:

The first work item in the proposed charter talks about deployment
models. We have checked all IETF documents on deployment and found out
that deployment always refers to an existing protocol. In this case,
DMM protocol does not exist.

I think there is easy fix to all the issues raised:

add one work item as the first work item on the development of
base Distributed Mobility Management Protocol.

If we have that then you can talk about deployment models, various
extensions as additional work items.

Regards,

Behcet

On Fri, Oct 3, 2014 at 2:38 PM, The IESG iesg-secret...@ietf.org wrote:
 The Distributed Mobility Management (dmm) working group in the Internet
 Area of the IETF is undergoing rechartering. The IESG has not made any
 determination yet. The following draft charter was submitted, and is
 provided for informational purposes only. Please send your comments to
 the IESG mailing list (iesg at ietf.org) by 2014-10-13.

 Distributed Mobility Management (dmm)
 
 Current Status: Active WG

 Chairs:
   Dapeng Liu liudap...@chinamobile.com
   Jouni Korhonen jouni.nos...@gmail.com

 Assigned Area Director:
   Brian Haberman br...@innovationslab.net

 Mailing list
   Address: dmm@ietf.org
   To Subscribe: https://www.ietf.org/mailman/listinfo/dmm
   Archive: http://www.ietf.org/mail-archive/web/dmm

 Charter:

 Mobility management solutions lie at the center of the wireless Internet
 and enable mobile devices to partake in IP networks anytime and
 anywhere. The IETF Distributed Mobility Management (DMM) working group
 (WG) specifies solutions for IP networks so that traffic between mobile
 and correspondent nodes can take an optimal route. DMM solutions aim for
 transparency above the IP layer, including maintenance of active
 transport level sessions when mobile hosts or mobile networks change
 their point of attachment to the Internet.

 Wireless network deployments have traditionally relied on hierarchical
 schemes that often lead to centralized deployment models, where a small
 number of mobility anchors manage both mobility and reachability for a
 mobile node. The DMM WG will consider the latest developments in mobile
 networking research and operational practice (i.e. flattening network
 architectures, the impact of virtualization, new deployment needs as
 wireless access technologies evolve in the coming years) and will
 describe how distributed mobility management addresses the new needs in
 this area better than previously standardized solutions.

 A topic of particular focus will be mobility anchoring in this new
 context, and the DMM working group is chartered to work on
 maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC
 5213, RFC 5844, RFC , RFC 5568, and RFC 6275) as well as new
 approaches which capitalize on other protocols specified by the IETF.
 For example, mobility management in a limited area, such as within an
 autonomous system, is not strictly limited to mentioned IP mobility
 protocols but can be any existing or a new protocol solution enabling
 the movement of a mobile node such as routing protocols. When extending
 protocols that are not based on Mobile IP, DMM solutions will have to be
 reviewed by the corresponding WGs.

 IPv6 is assumed to be present in both the mobile host/router and the
 access networks. DMM solutions are primarily targeted at IPv6
 deployments and are not required to support IPv4, in particular for the
 case where private IPv4 addresses and/or NATs are used. DMM solutions
 must maintain backward compatibility:  If the network or the mobile
 host/router does not support the distributed mobility management
 protocol that should not prevent the mobile host/router gaining basic
 access (i.e., nomadic) to the network.

 Contrary to earlier IP mobility protocols, mobility management signaling
 paths and end-user traffic forwarding paths may differ. Further,
 mobility-related functions may be located in separate network nodes. DMM
 solutions should not distinguish between physical or virtualized
 networking functions. Whenever applicable, clarifications and additional
 features/capabilities for specific networking function deployment
 models, e.g. in virtualized environments, are in-scope and encouraged.
 Solutions may also specify the selection between the care-of addresses
 and home address(es)/prefix(es) for different application use cases.

 The working group will produce both informational architectural and
 standards track protocol solutions on the following work item topics.

   o Distributed mobility management deployment models and scenarios:
 describe the target high-level network architectures and
 deployment models where distributed mobility management
 protocol solutions would apply.

   o Enhanced mobility anchoring: define protocol solutions for a
 gateway and mobility anchor assignment 

Re: [DMM] Agenda building for IETF 91

[Behcet Sarikaya]

Hi Fred,

I will make comments on your draft
if you promise to make comments on other solution drafts.

Regards,

Behcet

On Thu, Oct 9, 2014 at 10:28 AM, Templin, Fred L
fred.l.temp...@boeing.com wrote:
 Hi Jouni and Dapeng,

 I would like to request a 20min slot to discuss aspects of AERO that have not 
 been
 covered during the interim calls. Aspects include:

   1) DHCPv6 Service Model and IPv6 link-local address forming
   2) IPv6 Neighbor Discovery mobility signaling
   3) AERO mobility scenarios (intra-network, Internet-wide, proxy AERO)
   4) AERO correspondent node capability discovery

 Additionally, your call for presentations said that during the interims some 
 topics
 have already been presented in detail and those are not likely to be repeated 
 during
 the f2f meeting. However, I would like to note that there were only a few 
 people
 on the call when I presented the AERO BGP routing system, and some key working
 group participants were not present. So, I would like to request an 
 additional 10mins
 to add another item to those requested above as:

   5) AERO BGP routing system for enhanced anchoring

 bringing the total presentation time to 30min.

 Please let me know whether this request can be accommodated, either partially
 or in its entirety.

 Thanks - Fred
 fred.l.temp...@boeing.com

 -Original Message-
 From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
 Sent: Thursday, October 09, 2014 5:25 AM
 To: dmm@ietf.org
 Cc: Dapeng Liu
 Subject: [DMM] Agenda building for IETF 91

 Folks,

 Honolulu meeting is getting close.. we have asked for a 2.5h
 slot.  Hopefully we are by then already executing our new
 charter.

 We will have updates from work teams (and also reserve time for
 discussions)

 We will accept presentations (that fall into the charter scope)
 selectively. So feel free to ask for a slot. Note that during
 the interims some topics have already been presented in detail
 and those are not likely to be repeated during the f2f meeting.

 - Jouni  Dapeng

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WG Review: Distributed Mobility Management (dmm)

[Behcet Sarikaya]

Hi Alex,

Added to the point you made, I have concerns on

Enhanced mobility anchoring work item text and the references made
there (BTW among others).

The RFCs cited there, RFC 6097, 6463, and 5142 all progressed after
the base protocol was developed,  RFC 3775 or MIPv6 for 5142 and  RFC
5213 or PMIPv6 for 6097 and 6363.
They were extensions to what the protocol had offering some more
advanced methods.

My concern is DMM is being rechartered to develop the base solution.
How could the base protocol be held to such a high standard even
before its existence?

I have similar concerns on the other work items and I think they carry
similar sense.

My suggestion is a base DMM protocol as an integrated solution has to
be developed first and not developed in so many pieces.

And then bring those three work items (or similar) up  as a rechartering issue.

Regards,

Behcet

On Wed, Oct 8, 2014 at 9:23 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
 Jouni,

 Thank you for the message.

 Here are the modifications:

 Where the Charter mentions Mobile IPv6 protocol family (RFC x, y, z) it
 should also mention RFC 3963 and RFC 5177.

 (these RFCs were mentioned in past versions but disappeared somehow).

 Where the Charter says The working group may decide to extend the current
 milestones based on the new information and knowledge gained during working
 on other documents listed in the initial milestones. Possible new documents
 and milestones must still fit into the overall DMM charter scope as outlined
 above. Milestones:[empty]

 Please clarify that initial milestones is RFC 4888, RFC 4889,
 draft-ietf-dmm-best-practices-gap-analysis-08).

 Alex


 Le 08/10/2014 15:00, Jouni a écrit :

 Alex,

 Do you have a specific change to the text in mind? The charter text
 uses systematically mobile host/router to make sure mobile routers
 are not forgotten. However, charter also allows solutions that are
 not specifically tailored to mobile routers.

 Jouni



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Going forward with the DMM work items

[Behcet Sarikaya]

Hi Satoru,

Thank you for your comments on my draft, we will consider them in
revising it next time.

Let me say that I lived in Japan more than 7 years and I can probably
state that I am a bit familiar with the culture.
So my translation of your views is that these things happen in IETF
and we should live with them.

Yes, I agree that it happens but in IETF there is also freedom of
expression. We can and we should point the discrepancies and there is
nothing wrong to say that this (whatever it is) is wrong, people will
respect you more if you do that.

 Regards,

Behcet

On Tue, Oct 7, 2014 at 2:31 AM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
 Hi Behcet,


 On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya sarikaya2...@gmail.com
 wrote:


 I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi
 we proposed new approaches like SDN.


 Please don't get me wrong. My position hasn't been changed. BGP is used to
 forwarding path management signaling.

 In your draft, XMPP is the protocol that has same role of BGP. Good idea, it
 is a pub-sub system as same as BGP. You may need to define data model for
 dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs
 either xmpp, netconf, or forces.

 I suppose that you might want to adopt end-system VPN
 (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data
 modeling. (actually it is BGP. :-) And, as you may know that there is a
 draft which mentions about use case of BGP in i2rs.
 (http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases)


 Having said that I don't think that the charter text on forwarding
 path and signaling is talking about the same thing.


 Interesting. What do you expect for the charter text?
 Why not you ask Marco, Anthony and Alper to explain their thought?




 In DMM fir WiFi we also adopted the anycast discovery, what is wrong with
 that?


 How do you find the anycast address itself?




 Yes I agree, maybe other techniques like AAA can be worked out. Why
 not do it as extensions?


 I suppose that it would be a part of enhanced anchoring work, isn't it?



 Really? My thinking was that vEPC does not need any involvement from
 MN because the prefix assigned to MN does not change.

 As I mentioned in my more recent mail, I think this item is based on
 2102 solution proposals in which MN had to deal with many prefixes.

 Can you clarify which network nodes need exposure to MN mobility
 state? The ones on the path already know MN prefix, right?


 Quite not. I meant disclosing mobility information to network node that
 likes such as BGP speaker.



 So you are saying that these three items gave you some good ideas to
 think about on how you can improve your solution, vEPC.


 In my view, the charter items work well to achieve vEPC architecture model,
 yes.
 More precisely, as the result of discussions which I had so far with many
 dmm people, I have noticed some parts which the draft needs more work to
 achieve the architecture model.


 You are indicating that there is a major solution proposal, i.e. vEPC
 by you, but that can be improved here and there.

 You are missing the point that such a view point is not yet agreed by the
 group.


 I know. So I am trying to express my thought, and then we can recognize
 differences each other, and we can discuss. It's normal process in the ietf
 I think.



 Without such an agreement on the base, isn't it quite concerning what
 the WT's or DT's will do?

 My understanding is that the formation of WT's or DT's is another way
 of saying that we don't like all those solutions out there, we will
 design our own solutions to the above 3.


 I guess wg management, who are responsible to establish dmm standard, expect
 standardizing dmm solution would be very hard work because they find many
 variants for it. In that situation, it would be reasonable that they appoint
 some persons to lead the work. I really appreciate those persons who
 volunteer to take that role to out consolidated solution.

 Cheers,
 --satoru

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Going forward with the DMM work items

[Behcet Sarikaya]

The point is that the way the charter is being interpreted is
we don't need solutions and we won't care if there are some,

instead we will build the solution in five-six pieces from zero in DTs.

Behcet

On Mon, Sep 29, 2014 at 11:34 AM, Templin, Fred L
fred.l.temp...@boeing.com wrote:
 Hi Behcet,

 -Original Message-
 From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
 Sent: Monday, September 29, 2014 8:50 AM
 To: Templin, Fred L
 Cc: Brian Haberman; dmm@ietf.org
 Subject: Re: [DMM] Going forward with the DMM work items

 Hi Fred,


 On Fri, Sep 26, 2014 at 2:34 PM, Templin, Fred L
 fred.l.temp...@boeing.com wrote:
  Hi Behcet,
 
  -Original Message-
  From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
  Sent: Friday, September 26, 2014 12:22 PM
  To: Brian Haberman
  Cc: dmm@ietf.org
  Subject: Re: [DMM] Going forward with the DMM work items
 
  Hi Brian,
 
  You deleted maybe by mistake the first three paragraphs of my previous 
  mail.
 
  Let me add to those one more point:
 
  Previously mobility groups in IETF produced single protocols like
  Mobile IP or Proxy Mobile IP.
  These protocols have seen some operator adoption, of course not much but 
  some.
  This time we will be asking the operators to adopt exposing mobility
  state protocol, enhanced mobility anchoring protocol and forwarding
  path and signaling protocol (maybe forwarding path protocol and
  signaling protocol)l.
  And maybe deployment models protocol which was in the charter but
  somehow got dropped.
  How is that going to happen?

 Do you plan to divide your solution into

 exposing mobility state protocol,
 enhanced mobility anchoring protocol.
  forwarding path protocol
 signaling protocol ?

 That is the way things are going.

 All of these things I think have areas of overlap with aspects
 of the AERO proposal.

 Otherwise you are off track.

 I think the best I can do is represent the AERO proposal and speak
 to the areas where there is overlap. I think we have already
 established that AERO solves the tunnel MTU problem and that has
 applicability outside of just AERO. I am also feeding some of my
 correspondent capability discovery ideas to Alper and that again
 has wider applicability. The AERO NBMA model is being discussed
 in relation to the MIP/PMIP point-to-point model. Signaling based
 on plain old DHCPv6 and IPv6ND instead of specialized Mobility
 Headers has also been discussed.

 So, maybe I'm not seeing the forest for the trees but if you
 think I am off track what am I supposed to do about it? Complain,
 or continue to conduct a productive investigation as I am already
 doing?

  Anyway these are my concerns, I could not attend Interim call #2, I
  believe many people could not including Jouni.
 
  Jouni was able to attend the call. I was on the call and asked the
  question as to whether non-MIPv6/PMIPv6 solutions could be considered
  and the answer I got (I think from Jouni) was possibly.
 
  People should speak up, otherwise it appears like it is only my issue.
 
  AERO is a solution alternative that I would like to see taken under
  wider consideration within this domain. I think that is starting to
  happen through some of the recent list discussions, so others on the
  list should now be coming aware of it. I also plan to attend IETF91
  where I would ask for another AERO presentation timeslot if it would
  please the wg and the chairs.
 
  So, it seems to me that I am already doing all I can. Do you think
  I should be doing more?

 I think you are trying to push your own solution

 I am conducting an investigation. Others have joined me in a friendly
 exchange of ideas. Is it the wrong approach?

 and you think that you are effective in it.

 Which means that you think I am not effective in it?

 I think DMM should see the big picture and everybody, including Ryuji,
 Satoru and others should speak up.

 Sure, it would be good to hear from them. I have already specified
 a BGP-based distributed mobility management scheme in both the AERO
 spec and earlier in RFC6179. (I have read their draft; I have no way
 of knowing whether they have read my documents.)

 Thanks - Fred
 fred.l.temp...@boeing.com

 Regards,

 Behcet

 
  Thanks - Fred
  fred.l.temp...@boeing.com
 
  Regards,
 
  Behcet
 
  On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman
  br...@innovationslab.net wrote:
  
  
   On 9/26/14 11:14 AM, Behcet Sarikaya wrote:
  
  
   My question is we do that three four solution drafts and some of them
   implemented.
   What do we do with them?
  
   My expectation, as AD, is that the WG will assess the drafts presented
   by these teams for adoption.  People's opinion of those drafts should
   not be influenced by the fact they were written by a team.
  
  
   My advice to those colleagues wishing to lead the design teams is to
   please come up with your own solution and get into the race with
   others.
  
   Race?
  
   How come they can get the hat of DT lead

Re: [DMM] Interim call #3 approaching

[Behcet Sarikaya]

Hi Jouni,

On Mon, Sep 29, 2014 at 6:51 AM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 Folks,

 The interim call #3 is approaching and it is time for the agenda building.


Please mention the date. When I saw this mail I thought the call was
on Sept. 30 :-)


 Work Team leads should prepare to give an update on their side. Other than
 that if you have something DMMish to share, let the chairs know.

Please give the right name. I think AD says it is DT.

Regards,

Behcet

 - Jouni  Dapeng

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Going forward with the DMM work items

[Behcet Sarikaya]

Hi Fred,


On Fri, Sep 26, 2014 at 2:34 PM, Templin, Fred L
fred.l.temp...@boeing.com wrote:
 Hi Behcet,

 -Original Message-
 From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
 Sent: Friday, September 26, 2014 12:22 PM
 To: Brian Haberman
 Cc: dmm@ietf.org
 Subject: Re: [DMM] Going forward with the DMM work items

 Hi Brian,

 You deleted maybe by mistake the first three paragraphs of my previous mail.

 Let me add to those one more point:

 Previously mobility groups in IETF produced single protocols like
 Mobile IP or Proxy Mobile IP.
 These protocols have seen some operator adoption, of course not much but 
 some.
 This time we will be asking the operators to adopt exposing mobility
 state protocol, enhanced mobility anchoring protocol and forwarding
 path and signaling protocol (maybe forwarding path protocol and
 signaling protocol)l.
 And maybe deployment models protocol which was in the charter but
 somehow got dropped.
 How is that going to happen?

Do you plan to divide your solution into

exposing mobility state protocol,
enhanced mobility anchoring protocol.
 forwarding path protocol
signaling protocol ?

That is the way things are going.
Otherwise you are off track.



 Anyway these are my concerns, I could not attend Interim call #2, I
 believe many people could not including Jouni.

 Jouni was able to attend the call. I was on the call and asked the
 question as to whether non-MIPv6/PMIPv6 solutions could be considered
 and the answer I got (I think from Jouni) was possibly.

 People should speak up, otherwise it appears like it is only my issue.

 AERO is a solution alternative that I would like to see taken under
 wider consideration within this domain. I think that is starting to
 happen through some of the recent list discussions, so others on the
 list should now be coming aware of it. I also plan to attend IETF91
 where I would ask for another AERO presentation timeslot if it would
 please the wg and the chairs.

 So, it seems to me that I am already doing all I can. Do you think
 I should be doing more?

I think you are trying to push your own solution and you think that
you are effective in it.

I think DMM should see the big picture and everybody, including Ryuji,
Satoru and others should speak up.

Regards,

Behcet


 Thanks - Fred
 fred.l.temp...@boeing.com

 Regards,

 Behcet

 On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman
 br...@innovationslab.net wrote:
 
 
  On 9/26/14 11:14 AM, Behcet Sarikaya wrote:
 
 
  My question is we do that three four solution drafts and some of them
  implemented.
  What do we do with them?
 
  My expectation, as AD, is that the WG will assess the drafts presented
  by these teams for adoption.  People's opinion of those drafts should
  not be influenced by the fact they were written by a team.
 
 
  My advice to those colleagues wishing to lead the design teams is to
  please come up with your own solution and get into the race with
  others.
 
  Race?
 
  How come they can get the hat of DT lead and produce something and get
  priority over others who worked so hard?
 
  First of all, the chairs are well within their right to appoint DT
  leads.  They could have appointed all the other slots on the DT as well,
  but chose to ask for volunteers.
 
  I do not see anything in Jouni's note that indicates that a team's
  output gets any preferential treatment.  The rules of the IETF prevent 
  that.
 
  To re-enforce Jouni's last sentence...
 
  These documents will be equivalent to any individual produced I-D, 
  though.
 
  Regards,
  Brian
 
 
 
  ___
  dmm mailing list
  dmm@ietf.org
  https://www.ietf.org/mailman/listinfo/dmm
 

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Going forward with the DMM work items

[Behcet Sarikaya]

Hi Jouni,

I don't see anything in the charter regarding the design teams or
working teams. I also mentioned this in the list and there was no
objection.

On what basis you are forming the working teams?

We currently have many solution drafts and I can not see any of them
dividing the solution as exposing mobility state, enhanced mobility
anchoring or forwarding path and signaling.

These three items were mentioned by certain people which I believe do
not constitute the consensus in DMM. Yes the charter had those but my
interpretation was it was for the purpose of abstracting the solution
into some pieces. I have never interpreted them to be the requirements
to divide the final DMM protocol like this.

My question is we do that three four solution drafts and some of them
implemented.
What do we do with them?

My advice to those colleagues wishing to lead the design teams is to
please come up with your own solution and get into the race with
others.
How come they can get the hat of DT lead and produce something and get
priority over others who worked so hard?

Regards,

Behcet

On Fri, Sep 26, 2014 at 12:51 AM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 Folks,

 In the interim call #2 we agreed to form working teams. We got three
 volunteers to run up those:

 o Alper will take care of coordinating exposing mobility state..
 o Anthony will take care of coordinating enhanced mobility anchoring..
 o Marco will take care of coordinating forwarding path and signaling..

 The above gentlement will arrange calls for brainstorming that are open for
 everyone to participate. The process is open - about equivalent to a design
 team, you just don't need to signup for one. Just keep in mind that it is
 good to concentrate on a limited amount of work items.

 The working teams, if they so manage, will produce the solution I-D(s).
 These documents will be equivalent to any individual produced I-D, though.

 - Jouni  Dapeng

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] A Day in the Life of an Enterprise Mobile Device User

[Behcet Sarikaya]

On Fri, Sep 12, 2014 at 4:36 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
 Le 11/09/2014 00:00, Sri Gundavelli (sgundave) a écrit :

 Hi Fred,

 On 9/4/14 7:50 AM, Templin, Fred L fred.l.temp...@boeing.com wrote:

 No, in that VPN is cited in the scenario and VPN+Mobile IP are not
 working well together.


 Right - switching between VPN and non-VPN will be important for
 enterprise network mobile device users.



 I think Alex is referring to the DSMIP and IKEv2 interactions and I don't
 believe his point is about switching across VPN and non-VPN modes.

 FWIW, the 3GPP S2b interface allows a mobile node to perform handovers
 from 3GPP access (S5/S8) to non-3GPP access (S2b).

 There are other examples of Mobile VPN solutions that are deployed and are
 based on Mobile IP protocols. RFC5265 is only one example.


 Sri - I agree that specifications allow certain handovers.

 I am not sure what do you mean by Mobile VPN?  Mobile IP using a MH-HA
 tunnel with a VPN-style tunnel?  A VPN which changes the source address with
 a new IKE exchange?  These are two different things.

 In my experience, once I successfully set up a VPN tunnel on a Host computer
 its Mobile IP implementation will no longer work, and vice-versa; although
 each one can support mobility ok, independently, to a certain extent.


Alex, there is something called MOBIKE RFC 4621. I think it moves
IPSec tunnel when MN's address changes. So that could be used with
VPN.

Regards,

Behcet


 Alex




 Regards
 Sri






 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM Interim call #2 - agenda forming

[Behcet Sarikaya]

Jouni, why don't we cancel this one (#2) and do the next one (#3) with
an agenda?
I hope Alper can attend :-)

Regards,

Behcet

On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen jouni.nos...@gmail.com wrote:

 It seems I sent this to a wrong receiver.. that explains why it did not
 appear on the list.

 - Jouni

  Alkuperäinen viesti / Orig.Msg. 
 Aihe: DMM Interim call #2 - agenda forming
 Päiväys: Mon, 08 Sep 2014 23:43:24 +0300
 Lähettäjä: Jouni Korhonen jouni.nos...@gmail.com
 Vastaanottaja: dmm-...@tools.ietf.org
 CC: jouni.nos...@gmail.com, Dapeng Liu liudap...@chinamobile.com

 Folks,

 The next interim is close. Assuming there are no overwhelming amount of
 comments to the re-charter text, we are ready to start setting up the
 work split on the solution space! Remember the discussion and the
 minutes from the IETF#90 Friday session. No other agenda items are
 planned for the next interim.

 - Jouni  Dapeng


 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

Hi Charlie,

Check this out:

http://tools.ietf.org/id/draft-sarikaya-dmm-for-wifi-00.txt

Regards,

Behcet

On Thu, Sep 4, 2014 at 5:31 AM, Charles E. Perkins
charl...@computer.org wrote:

 Hello folks,

 I have asked this same question many times, in different words...

 Namely, if we design a solution that fits the requirements, and bridges
 the gaps as analyzed in the gap analysis document, have we succeeded?

 Or, is there a requirement for the work to be adopted by 3GPP?

 What if we design for IEEE 802 Wireless, which is currently carrying the
 preponderance of the world's wireless data, and will almost assuredly
 continue to carry a greater proportion?

 Regards
 Charlie P.



 On 9/4/2014 3:14 AM, Alexandru Petrescu wrote:


 Hi,

 


 In DMM, precedents and the keen NETEXT, there seems to be a
 hard-rooted disconnect between the product developped - (P)Mobile IP -
 and the deployments.  We know for a fact that 3GPP deployments
 (2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs do
 mention Mobile IP. To such a point that I wonder whether 3GPP has not
 the same disconnect as here.

 On another hand, we do have indications of where (P)Mobile IP is used
 - the trials, the projects, the kernel code, and not least the
 slideware attracting real customers.

 The worry: develop DMM protocol while continuing the disconnect.

 Alex








 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm



 --
 Regards,
 Charlie P.


 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

Hi Alex,


On Thu, Sep 4, 2014 at 6:36 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
 Le 04/09/2014 12:31, Charles E. Perkins a écrit :


 Hello folks,

 I have asked this same question many times, in different words...

 Namely, if we design a solution that fits the requirements, and bridges
 the gaps as analyzed in the gap analysis document, have we succeeded?


 My answer is no.  As of now it may look as a homework - yes it solves the
 problem statement, yes it gets a high grade, yes it can.  But what if no,
 deployments wouldn't need it.


 Or, is there a requirement for the work to be adopted by 3GPP?


 Even then - even if there were a req from 3GPP  (a row in an excel sheet, an
 IPv6 mentioned in a 3GPP doc) - one would rather need a commitment of
 deployment from 3GPP.


 What if we design for IEEE 802 Wireless, which is currently carrying the
 preponderance of the world's wireless data, and will almost assuredly
 continue to carry a greater proportion?


 Yes, and with the advent of cheap 802.11ac's huge bandwidth (1.2GB/s) one of
 the strong selling points of Mobile IP is the ability to offer session
 continuity when handover cellular/802-Wireless - the heterogeneity to some
 extent.

 Additionally, there are many possibilities of doing Mobile IP in a
 802-Wireless only environment: large indoor hotspot areas, long 11p-covered
 roads, etc.  These are exhibited in trials.

 But, sorry for saying again, one couldn't stop wondering whether these are
 to be embraced by deployments.

 Why is the 'tethering' application on operator's smartphones preferring to
 use a form of IPv6 prefix sharing rather than Mobile IP/NEMO?

 Why there is no session continuity app in these smartphones?

 Why one has to always click on some icon on their smartphones to (1) switch
 on/off 'mobile data', (2) turn on/off WiFi?


Good questions.

I think that 3GPP SA1 work reported by Alper is addressing this issue
in terms of classifying the flows. They identify certain class of
flows like interactive calls where you would definitely need session
continuity. 3GPP thinks that in most other cases like Web browsing you
don't.


So in dmm we can say that the protocol dmm is going to develop could
be a candidate solution for those flows that you need session
continuity.

I don't think IETF can do more.

Regards,

Behcet
 Given these behaviours one may wonder how much the session continuity aspect
 is need by end users.

 There are some answers I heard about this... for example when one needs a
 session to be stable one by instinct will try to not move.  Hardly can one
 walk and talk: two things at a time.

 Alex



 Regards
 Charlie P.



 On 9/4/2014 3:14 AM, Alexandru Petrescu wrote:


 Hi,

 

 In DMM, precedents and the keen NETEXT, there seems to be a
 hard-rooted disconnect between the product developped - (P)Mobile IP -
 and the deployments.  We know for a fact that 3GPP deployments
 (2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs do
 mention Mobile IP. To such a point that I wonder whether 3GPP has not
 the same disconnect as here.

 On another hand, we do have indications of where (P)Mobile IP is used
 - the trials, the projects, the kernel code, and not least the
 slideware attracting real customers.

 The worry: develop DMM protocol while continuing the disconnect.

 Alex








 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm





 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

On Wed, Sep 3, 2014 at 12:07 AM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 We were on this in yesterday's interim call. We have a proposal text now.
 You were also on the call but I did not record you commenting anything
 during the discussion we had on this particular topic.

I had leave early due to doctor's appointment.

 Are you now saying
 the resolution we have now in the charter text is not adequate?


Distributed mobility management deployment models and scenarios:
describe the target high-level network architectures and
deployment models where distributed mobility management
protocol solutions would apply.

Behcet: the above text does not reflect my comments.
I am against any deployment work before we decide on a solution (and
there is currently no draft on this).
This is strongly supported by IETF work on deployment as well as 3GPP.

I am also concerned on the time DMM is taking on dressing up the
charter text. I remind you on what Jari Arkko who is founding AD for
DMM said in Toronto admin plenary:
WGs should have  solution work from day 1.

He also emphasized importance of running code.

It is not that we don't have solutions and it is claimed that two of
them have been implemented.

Regards,

behcet



 - JOuni

 9/2/2014 11:39 PM, Behcet Sarikaya kirjoitti:

 On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen jouni.nos...@gmail.com
 wrote:

 Behcet,

 Obviously that protocols are known that the intended deployment is going
 to
 use. The details what goes inside that protocol are not. This holds for
 my
 example case 3GPP as well.

 We do not need to into same level of detail that e.g. 3GPP stage-2 has
 detailing all signaling flows and so on. I believe we as a WG are
 competent
 enough to make a fine division what level of detail is left for the
 deployment models and scenarios and what goes into protocol solutions.


 I hope you read previous mails on this issue.

 I think it clear that 3GPP agrees with IETF on the interpretation of
 deployment. How can we close our eyes on this and try to put the horse
 before the cart?

 Why not simply remove it?

 Regards,
 Behcet



 - Jouni

 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti:

 On Mon, Sep 1, 2014 at 3:25 AM, Jouni jouni.nos...@gmail.com wrote:



 Alper,

 I hear your concern. Anyway, the division here is similar to (3GPP)
 stage-2 and stage-3 work. The deployment models and scenarios are
 the
 stage-2 descriptions and then we also need the protocol level solutions
 that
 are in separate documents.


 Thanks Alper for raising this issue.

 3GPP Stage 2 like in SA2 documents are architecture documents.
 I don't understand what is going on here.

 I am looking at 23.402 on Architecture Enhancements for non-3GPP
 accesses.

 Yes, this document talks about deployment in just a few places, here
 is one occurrence: on page 64, PCC deployment options
 on page 94, PMIP based S5/S8 deployments, etc.

 So in all cases the protocol, i.e. PCC or PMIP is known.

 Regards,

 Behcet


 Makes sense?

 - Jouni


 On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote:

 Okay, we are not going to define how the existing 3FPP system works -
 that knowledge is assumed. What I thought goes into the document, for
 example, in the case of 3GPP system would be identifying the
 architecture
 changes or modifications needed. If the deployment model assumes all
 network
 functions are virtualized, the document states that and lays out the
 architecture based on that. Satoru's  Ryuji's vEPC deployment model
 (based
 on their solution) is IMHO a good example of what could be
 documented. The
 similar applies for other system architectures such as SP Wi-Fi etc.


 Jouni,

 The architecture changes would be based on the a specific
 solution.
 So, as part of describing a solution one can be talking about what you
 are
 suggesting above. But I don't understand how we can be talking about
 deployment models and scenarios before we agree on the solutions.

 Alper




  o Enhanced mobility anchoring: define protocol solutions for
 a
gateway and mobility anchor assignment and mid-session
 mobility
anchor switching that go beyond what has been specified,
 for
example, in RFC 6097, 6463, and 5142. Traffic steering
associated with the anchor switch is also in-scope if
 deemed
appropriate.

  o Forwarding path and signaling management: the function
that handles mobility management signaling interacts with
 the
DMM network elements for managing the forwarding state
associated with a mobile node's IP traffic. These two
 functions
may or may not be collocated. Furthermore, the forwarding
 state
may also be distributed into multiple network elements
 instead
of a single network element (e.g., anchor). Protocol
 extensions
or new protocols will be specified to allow the above
 mentioned
forwarding path and signalling management.


 I cannot separate mobility anchoring from fwding

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

Hi Brian,

On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman
br...@innovationslab.net wrote:
 Just for clarification...

 On 9/3/14 12:22 PM, Behcet Sarikaya wrote:


 I am also concerned on the time DMM is taking on dressing up the
 charter text. I remind you on what Jari Arkko who is founding AD for
 DMM said in Toronto admin plenary:
 WGs should have  solution work from day 1.

 Not should, but rather could.  Not all WGs need to have
 requirements, frameworks, architecture, etc. That is why this type of
 discussion during charter development is important.

Here is the quote:
WGs should have solution work from day 1

from page 22 of Jari's slides at:

http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf

BTW we already did the requirements and gap analysis, etc. The
architecture in our case is defined elsewhere, like 3GPP and everybody
in this group is familiar with 3GPP architecture.




 He also emphasized importance of running code.

 Running code is good thing.  So is an understanding of customer needs
 (in this case, other SDOs).

Absolutely.

Regards,

Behcet

 Regards,
 Brian


 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 Behcet,

 Obviously that protocols are known that the intended deployment is going to
 use. The details what goes inside that protocol are not. This holds for my
 example case 3GPP as well.

 We do not need to into same level of detail that e.g. 3GPP stage-2 has
 detailing all signaling flows and so on. I believe we as a WG are competent
 enough to make a fine division what level of detail is left for the
 deployment models and scenarios and what goes into protocol solutions.


I hope you read previous mails on this issue.

I think it clear that 3GPP agrees with IETF on the interpretation of
deployment. How can we close our eyes on this and try to put the horse
before the cart?

Why not simply remove it?

Regards,
Behcet



 - Jouni

 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti:

 On Mon, Sep 1, 2014 at 3:25 AM, Jouni jouni.nos...@gmail.com wrote:


 Alper,

 I hear your concern. Anyway, the division here is similar to (3GPP)
 stage-2 and stage-3 work. The deployment models and scenarios are the
 stage-2 descriptions and then we also need the protocol level solutions that
 are in separate documents.


 Thanks Alper for raising this issue.

 3GPP Stage 2 like in SA2 documents are architecture documents.
 I don't understand what is going on here.

 I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses.

 Yes, this document talks about deployment in just a few places, here
 is one occurrence: on page 64, PCC deployment options
 on page 94, PMIP based S5/S8 deployments, etc.

 So in all cases the protocol, i.e. PCC or PMIP is known.

 Regards,

 Behcet

 Makes sense?

 - Jouni


 On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote:

 Okay, we are not going to define how the existing 3FPP system works -
 that knowledge is assumed. What I thought goes into the document, for
 example, in the case of 3GPP system would be identifying the architecture
 changes or modifications needed. If the deployment model assumes all 
 network
 functions are virtualized, the document states that and lays out the
 architecture based on that. Satoru's  Ryuji's vEPC deployment model 
 (based
 on their solution) is IMHO a good example of what could be documented. The
 similar applies for other system architectures such as SP Wi-Fi etc.


 Jouni,

 The architecture changes would be based on the a specific solution.
 So, as part of describing a solution one can be talking about what you are
 suggesting above. But I don't understand how we can be talking about
 deployment models and scenarios before we agree on the solutions.

 Alper




 o Enhanced mobility anchoring: define protocol solutions for a
   gateway and mobility anchor assignment and mid-session
 mobility
   anchor switching that go beyond what has been specified, for
   example, in RFC 6097, 6463, and 5142. Traffic steering
   associated with the anchor switch is also in-scope if deemed
   appropriate.

 o Forwarding path and signaling management: the function
   that handles mobility management signaling interacts with the
   DMM network elements for managing the forwarding state
   associated with a mobile node's IP traffic. These two
 functions
   may or may not be collocated. Furthermore, the forwarding
 state
   may also be distributed into multiple network elements
 instead
   of a single network element (e.g., anchor). Protocol
 extensions
   or new protocols will be specified to allow the above
 mentioned
   forwarding path and signalling management.


 I cannot separate mobility anchoring from fwding path and
 signaling management.
 Wherever you want to set your anchor or move your anchor to, you'd
 need signaling
 and setting up data path. The two are inseparable.
 Having said that, I'm OK to keep the current work item descriptions
 and finalize
 rechartering. Once we have detailed discussions about the breakdown

 of the work, we

 can come back and refine the goals and milestones (as already stated

 below [*]).

 The enhanced mobility anchoring above is/was rather MIP type
 solutions
 influenced with anchors like we understand today, while the
 forwarding path and signaling management was meant for more future
 oriented solutions where the forwarding path does not necessarily
 have
 anything mobility specific etc.


 (Just FYI: It's not possible to gather what you are saying from
 reading
 the charter. Different people reading the charter may not have the
 same
 understanding. But like I said, this is just FYI, I can live with this
 text until we come back and refine it later).


 Ok. I'll try to clarify the point the text tries to make.

 - Jouni


 Thanks.

 Alper




 Any other opinions on collapsing these two?

 - Jouni

 o Exposing mobility state to mobile nodes and network nodes:
   define solutions that allow, for example, mobile nodes to
 select
   either a care-of address or a home address

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

On Mon, Sep 1, 2014 at 3:25 AM, Jouni jouni.nos...@gmail.com wrote:

 Alper,

 I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 
 and stage-3 work. The deployment models and scenarios are the stage-2 
 descriptions and then we also need the protocol level solutions that are in 
 separate documents.


Thanks Alper for raising this issue.

3GPP Stage 2 like in SA2 documents are architecture documents.
I don't understand what is going on here.

I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses.

Yes, this document talks about deployment in just a few places, here
is one occurrence: on page 64, PCC deployment options
on page 94, PMIP based S5/S8 deployments, etc.

So in all cases the protocol, i.e. PCC or PMIP is known.

Regards,

Behcet
 Makes sense?

 - Jouni


 On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote:

 Okay, we are not going to define how the existing 3FPP system works - that 
 knowledge is assumed. What I thought goes into the document, for example, 
 in the case of 3GPP system would be identifying the architecture changes or 
 modifications needed. If the deployment model assumes all network functions 
 are virtualized, the document states that and lays out the architecture 
 based on that. Satoru's  Ryuji's vEPC deployment model (based on their 
 solution) is IMHO a good example of what could be documented. The similar 
 applies for other system architectures such as SP Wi-Fi etc.


 Jouni,

 The architecture changes would be based on the a specific solution. So, 
 as part of describing a solution one can be talking about what you are 
 suggesting above. But I don't understand how we can be talking about 
 deployment models and scenarios before we agree on the solutions.

 Alper




o Enhanced mobility anchoring: define protocol solutions for a
  gateway and mobility anchor assignment and mid-session mobility
  anchor switching that go beyond what has been specified, for
  example, in RFC 6097, 6463, and 5142. Traffic steering
  associated with the anchor switch is also in-scope if deemed
  appropriate.

o Forwarding path and signaling management: the function
  that handles mobility management signaling interacts with the
  DMM network elements for managing the forwarding state
  associated with a mobile node's IP traffic. These two functions
  may or may not be collocated. Furthermore, the forwarding state
  may also be distributed into multiple network elements instead
  of a single network element (e.g., anchor). Protocol extensions
  or new protocols will be specified to allow the above mentioned
  forwarding path and signalling management.


 I cannot separate mobility anchoring from fwding path and
 signaling management.
 Wherever you want to set your anchor or move your anchor to, you'd
 need signaling
 and setting up data path. The two are inseparable.
 Having said that, I'm OK to keep the current work item descriptions
 and finalize
 rechartering. Once we have detailed discussions about the breakdown
 of the work, we
 can come back and refine the goals and milestones (as already stated
 below [*]).

 The enhanced mobility anchoring above is/was rather MIP type solutions
 influenced with anchors like we understand today, while the
 forwarding path and signaling management was meant for more future
 oriented solutions where the forwarding path does not necessarily have
 anything mobility specific etc.


 (Just FYI: It's not possible to gather what you are saying from reading
 the charter. Different people reading the charter may not have the same
 understanding. But like I said, this is just FYI, I can live with this
 text until we come back and refine it later).

 Ok. I'll try to clarify the point the text tries to make.

 - Jouni


 Thanks.

 Alper




 Any other opinions on collapsing these two?

 - Jouni

o Exposing mobility state to mobile nodes and network nodes:
  define solutions that allow, for example, mobile nodes to select
  either a care-of address or a home address depending on an
  application' mobility needs. In order to enable this
  functionality, the network-side control functions and other
  networking nodes must also be able to exchange appropriate
  control information, as well as to the mobile nodes and their
  applications.

 The working group may decide to extend the current milestones based on
 the new information and knowledge gained during working on other
 documents listed in the initial milestones. [*]


 Cheers,

 Alper




 Possible new documents and
 milestones must still fit into the overall DMM charter scope as outlined
 above.

 Goals and Milestones:

 Feb 2015 - Submit 'The deployment models and scenarios' as a working
   group document(s). To be Informational RFC.

 Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group
   document. To be Proposed Standard.

 Feb 2015 - Submit 

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

On Thu, Jul 24, 2014 at 5:17 PM, Brian Haberman
br...@innovationslab.net wrote:


 On 7/24/14 6:01 PM, Behcet Sarikaya wrote:
 Hi Jouni,

 Regarding

 Distributed mobility management deployment models and scenarios:

 As I said in the session today I am having trouble understanding the
 deployment models.

 To me it sounds like doing the last thing first, i.e. after we get the
 dmm solution we work on how to deploy it (of course if the deployment
 has not already been considered by the solution).

 I may be interpreting the charter incorrectly, but I think there may be
 a disconnect.  I interpreted the the charter text as describing
 deployment models like:

 - Wi-Fi-based mobility management

 - Cellular (e.g., 3GPP) mobility management

 - Mixed technology mobility management

 - etc.

 If that above interpretation is what was intended, I think it makes
 sense to have that type of description available to guide solution
 development.

 If the above is not correct, then I suspect the charter needs some
 clarification.


If that is the case then I suggest calling it DMM usage scenarios or
use cases in real networks?

Use case work is done before solution work, so that I think is a good
match with DMM.

Regards,

Behcet
 Regards,
 Brian


 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

Hi Jouni,

Regarding

Distributed mobility management deployment models and scenarios:

As I said in the session today I am having trouble understanding the
deployment models.

To me it sounds like doing the last thing first, i.e. after we get the
dmm solution we work on how to deploy it (of course if the deployment
has not already been considered by the solution).

Is there an existing draft which comes close to this item so that I
can read and try to understand?

On

the expected high level network architectures

Is this about the architectures of the existing networks like 3GPP,
home networks, enterprise networks, etc.?

I hope you can shed some light into this.

Regards,

Behcet



On Thu, Jul 24, 2014 at 4:49 PM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 Folks,

 The latest charter draft can be found here:
 https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt

 The deadline for the text chnges are 31st July. I'll setup a call for next
 week so that those who want to dial in and have verbal commenting can do
 that. In a meanwhile, email works as usual for updates and comments on the
 text. The actual milestone dates are to be done last but suggestions are
 more than welcome.

 - Jouni  Dapeng

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF#90 DMM agenda update

[Behcet Sarikaya]

I am not against any work which is based on an existing draft. I spoke
against having a long presentation and there is no draft.

Another point here is, yesterday I discussed with Marco on this. Any
architecture and so called deployment proposal has a sense of solution
in it. I don't buy the argument that the architecture is generic and
that the deployment is generic.
At this point in time there is no such thing. Such proposals represent
the authors solution approach.They are reading other solution
proposals and they don't like some aspects in those solution drafts
and they want to present some alternative approaches.

So, as I said before, Marco, Sri, Pierrick, if there are any others,
are free to write drafts making it clear that in the draft they are
talking about their own solution. There is nothing wrong with it.

I hope this makes my point clear.

Regards,

Behcet

On Wed, Jul 23, 2014 at 4:36 AM,  dirk.von-h...@telekom.de wrote:
 Thanks Pierrick for the pointer!
 And FWIW also Marcos draft-liebsch-dmm-framework-03 addresses deployment and 
 architecture aspects for evaluating various approaches
 BR
 Dirk
 -Original Message-
 From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of pierrick.se...@orange.com
 Sent: Mittwoch, 23. Juli 2014 10:13
 To: sarik...@ieee.org; Sri Gundavelli (sgundave)
 Cc: dmm@ietf.org
 Subject: Re: [DMM] IETF#90 DMM agenda update



-Message d'origine-
De : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya
Envoyé : mardi 22 juillet 2014 19:04 À : Sri Gundavelli (sgundave) Cc :
dmm@ietf.org Objet : Re: [DMM] IETF#90 DMM agenda update

On Tue, Jul 22, 2014 at 12:00 PM, Sri Gundavelli (sgundave)
sgund...@cisco.com wrote:
 I think you are mixing the topics here.

I am not sure who?
How can you talk about deployment without having a solution?
Deployment where?


 Any case, I don't have plans to write one ..

I know that and that's why I kept asking, just in case you might change
your mind.

Maybe you can write a draft evaluating existing proposals from your
architecture and your deployment point of view.


 Worth to be considered IMHO: draft-liu-dmm-deployment-scenario

Behcet



 Sri



 On 7/22/14 9:56 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote:

You are talking about Gateway Initiated DS-Lite (RFC 6674).

That is a solution based on DS-Lite, i.e. a variation of DS-Lite or
RFC 6333.

Again, my plea to you, please come up with your draft and let WG see
what you propose.

That is the right way to go.

Behcet


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

 _

 Ce message et ses pieces jointes peuvent contenir des informations 
 confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
 exploites ou copies sans autorisation. Si vous avez recu ce message par 
 erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les 
 pieces jointes. Les messages electroniques etant susceptibles d'alteration, 
 Orange decline toute responsabilite si ce message a ete altere, deforme ou 
 falsifie. Merci.

 This message and its attachments may contain confidential or privileged 
 information that may be protected by law; they should not be distributed, 
 used or copied without authorisation.
 If you have received this email in error, please notify the sender and delete 
 this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been 
 modified, changed or falsified.
 Thank you.

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF#90 DMM agenda update

[Behcet Sarikaya]

On Wed, Jul 23, 2014 at 9:36 AM, Brian Haberman
br...@innovationslab.net wrote:


 On 7/23/14 10:16 AM, Behcet Sarikaya wrote:
 So my question is what guarantees that is the DT is going to produce
 the right solution and why repeat the history again?


 Who said that *if* a DT is formed that its output is considered special?

 http://www.ietf.org/iesg/statement/design-team.html


My point is that at this time in dmm I can not see any justification
for forming a design team to develop a solution or parts of a
solution.
We already have solutions and it seems like at least one of them is
implemented. I don't think it is reasonable to expect any deployment
now.
In view of this I am unable to see the need for some many items in the
proposed charter.

Regards,

Behcet

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF#90 DMM agenda update

[Behcet Sarikaya]

Hi Brian,


On Tue, Jul 22, 2014 at 9:58 AM, Brian Haberman
br...@innovationslab.net wrote:


 On 7/22/14 10:49 AM, Jouni Korhonen wrote:
 Folks,

 The agenda has been slightly updated (shuffling around the slots and
 arranging more time to the charter/next steps discussion). Some
 presenters are affected slightly (-5 minutes). see
 http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm

 Regarding the re-chartering and the next steps. We have a tight deadline
 to meet if we want to ship the new charter text to the next IESG
 telechat. Brian will reveal the gory details of the expected
 re-chartering process and timelines.

 We are also supposed to come up (again) with a rought agreement of the
 deployment architecture(s) that DMM functional elements map into.

Sorry but I don't understand why we have to work on deployment architectures?

I don't remember any such work before in IP mobility. Is there any RFC
that can educate me on this?

I understand that some architecture work is needed. As far as I know
almost all solution drafts have an architecture.
Wouldn't that be enough?

Kind regards,

Behcet

This
 will be discussed as a part of the re-chartering slot and recapping the
 discussions we had earlier.

 We are also supposed to come up with a rough agreement how to progress
 from now on. This could mean (note the conditionality here) a series of
 interim meetings and setting up small groups (or design teams) to work
 on the initial set of the solution space drafts. We need to step out of
 the progress every second IETF meeting mode ;)

 http://www.ietf.org/iesg/statement/interim-meetings.html


 Also keep in mind that the start of the new work poses some
 serialization whether we want or now: first stabilize charter  reach
 rough consensus on the deployment models/functional elements. These can
 be done in parallel. Note that rough consensus does not mean a ready
 spec or spec at all. Second execute with the solutions space.. the
 deployment models work might benefit from having a slight heads up
 before other drafts. These can be done in parallel, though. As a
 reminder, the charter may change on the route before it gets approved
 but we can do the opportunistic thing and start working as if the
 charter were already approved when the WG ships it.

 - Jouni  Dapeng

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF#90 DMM agenda update

[Behcet Sarikaya]

Hi Sri,


On Tue, Jul 22, 2014 at 10:16 AM, Sri Gundavelli (sgundave)
sgund...@cisco.com wrote:
 Behcet,

 Check some of the documents in MPLS/Routing areas.

Sorry, I am familiar with those areas, they are not in Intarea :-).


 DMM to most part is about deployment. Without bringing the deployment
 aspects, documenting DMM solutions will be immature.

I am looking at this Softwire document:

http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-04

This document is looking into models on how MAP can be deployed on
large-scale carrier networks.

But the catch is that MAP which is the solution protocol is already
defined in a different document by Softwire.

So the deployment models IF NEEDED follows the solution selection process.

May I suggest you to please come up with a draft including your ideas
on the architecture and solution and have it discussed like any other
protocol proposals? You may wish to add any deployment concerns there
in your draft if you like.

Also any architecture work will have implications on the solution and
if they are done at the WG level that practically means that a lot of
bias on the solutions which are already proposed will be imposed. I
don't think that is what the WG wants to do.

Regards,

Behcet





 Sri


 On 7/22/14 8:08 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote:

Hi Brian,


On Tue, Jul 22, 2014 at 9:58 AM, Brian Haberman
br...@innovationslab.net wrote:


 On 7/22/14 10:49 AM, Jouni Korhonen wrote:
 Folks,

 The agenda has been slightly updated (shuffling around the slots and
 arranging more time to the charter/next steps discussion). Some
 presenters are affected slightly (-5 minutes). see
 http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm

 Regarding the re-chartering and the next steps. We have a tight
deadline
 to meet if we want to ship the new charter text to the next IESG
 telechat. Brian will reveal the gory details of the expected
 re-chartering process and timelines.

 We are also supposed to come up (again) with a rought agreement of the
 deployment architecture(s) that DMM functional elements map into.

Sorry but I don't understand why we have to work on deployment
architectures?

I don't remember any such work before in IP mobility. Is there any RFC
that can educate me on this?

I understand that some architecture work is needed. As far as I know
almost all solution drafts have an architecture.
Wouldn't that be enough?

Kind regards,

Behcet

This
 will be discussed as a part of the re-chartering slot and recapping the
 discussions we had earlier.

 We are also supposed to come up with a rough agreement how to progress
 from now on. This could mean (note the conditionality here) a series of
 interim meetings and setting up small groups (or design teams) to work
 on the initial set of the solution space drafts. We need to step out of
 the progress every second IETF meeting mode ;)

 http://www.ietf.org/iesg/statement/interim-meetings.html


 Also keep in mind that the start of the new work poses some
 serialization whether we want or now: first stabilize charter  reach
 rough consensus on the deployment models/functional elements. These can
 be done in parallel. Note that rough consensus does not mean a ready
 spec or spec at all. Second execute with the solutions space.. the
 deployment models work might benefit from having a slight heads up
 before other drafts. These can be done in parallel, though. As a
 reminder, the charter may change on the route before it gets approved
 but we can do the opportunistic thing and start working as if the
 charter were already approved when the WG ships it.

 - Jouni  Dapeng

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF#90 DMM agenda update

[Behcet Sarikaya]

You are talking about Gateway Initiated DS-Lite (RFC 6674).

That is a solution based on DS-Lite, i.e. a variation of DS-Lite or RFC 6333.

Again, my plea to you, please come up with your draft and let WG see
what you propose.

That is the right way to go.

Behcet

On Tue, Jul 22, 2014 at 11:48 AM, Sri Gundavelli (sgundave)
sgund...@cisco.com wrote:
 Alternatively, you capture the deployment models and then identify the
 solution gaps or solutions that meet the goals ...

 Sorry, I am familiar with those areas, they are not in Intarea :-).


 RFC-6674; A solution driven by a deployment requirement.


 Sri


 On 7/22/14 9:36 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote:

Hi Sri,


On Tue, Jul 22, 2014 at 10:16 AM, Sri Gundavelli (sgundave)
sgund...@cisco.com wrote:
 Behcet,

 Check some of the documents in MPLS/Routing areas.

Sorry, I am familiar with those areas, they are not in Intarea :-).


 DMM to most part is about deployment. Without bringing the deployment
 aspects, documenting DMM solutions will be immature.

I am looking at this Softwire document:

http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-04

This document is looking into models on how MAP can be deployed on
large-scale carrier networks.

But the catch is that MAP which is the solution protocol is already
defined in a different document by Softwire.

So the deployment models IF NEEDED follows the solution selection process.

May I suggest you to please come up with a draft including your ideas
on the architecture and solution and have it discussed like any other
protocol proposals? You may wish to add any deployment concerns there
in your draft if you like.

Also any architecture work will have implications on the solution and
if they are done at the WG level that practically means that a lot of
bias on the solutions which are already proposed will be imposed. I
don't think that is what the WG wants to do.

Regards,

Behcet




___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM solution space categorization

[Behcet Sarikaya]

Hi all,

I am unable to understand why we are complicating life so much.
It seems like we forget the fact that this WG existed since 2012 and
many things happened since then.

Initially we had this simple categorization:

MIP-based approaches, those that are requiring a client at the MN,

PMIP-based approaches not requiring a client at the MN but some prefix
management may be needed due to the distributed approach.

Routing based approaches not requiring a client also not requiring
prefix management

My question is why these 3 categories are not enough?

Regards,

Behcet

On Mon, Jul 21, 2014 at 10:04 AM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 Alper,

 7/21/2014 5:38 PM, Alper Yegin kirjoitti:

 Jouni,


 I've updated the list with the I-Ds suggested by Behcet/Fred/Jouni.

 Please see below for my opinions about how each category relates to the
 overall work.
 Comments welcome.
 *
 *
 *
 *
 *1. Per-flow IP address configuration according to mobility needs*


 Exposing mobility state to mobile nodes and network nodes

 Apps indicating their mobility needs to the IP stack on the MN, and
 associated IP configuration signaling between the MN and the network.

 draft-bhandari-dhc-class-based-prefix-03
 draft-korhonen-dmm-prefix-properties-00.txt
 draft-yegin-dmm-ondemand-mobility-02


 Then we have a number of I-Ds from MIF:

 draft-kk-mpvd-ndp-support
 draft-kkb-mpvd-dhcp-support
 draft-kkbg-mpvd-id

 These intend to build the overall method of conveying the signaling
 between the network and the mn. There are no spacific use cases described
 for mobility yet but those are then amendments for the above.


 I am bringing these up because they _do_ propose a framework for MN-Network
 communication.. specifically when you need to add semantical information
 into prefix/link/etc information the network advertises to the MNs.

 - Jouni






 MIF problem space is different than DMM's.
 We should not create any dependency between the two.

 draft-liu-dmm-mobility-api


 I'll add that.

 Alper


 Above has extensions to RFC5014 for applications to check prefix
 properties.


 This category is essential, given that we all agree mobility will be
 treated on a per-flow basis.
 (and once we dive into the category, I'd say the aforementioned I-Ds are
 complementary).



 *2. Mobility solution selection *


 In my optinion this also fits under Exposing mobility state to mobile
 nodes and network nodes.

 MN determining the type of mobility solution(s) it'd apply to a given
 flow.

 draft-yegin-ip-mobility-orchestrator-00

 In recognition of L4+ mobility solutions (such as MPTCP, SIP, apps
 having their own), this also becomes essential for a DMM solution. Some
 people may argue, discussion is very welcome.



 *3. IP anchor selection*


 Enhanced mobility anchoring

 MN selecting the IP anchor node after it decides to use IP anchoring
 (whether in the access network or the core network).

 draft-aliahmad-dmm-anchor-selection-00.txt

 This category is supporting the Category 4, 5 and 6. This is about more
 intelligent way of picking the IP anchor once the type of anchor is
 determined.
 This may produce a standalone I-D, or may be folded into individual
 solutions in those categories.


 *4. Access network anchoring*


 Still related to Enhanced mobility anchoring. Many of these I-Ds handle
 the anchor change issues (like tunneling between the anchors).

 Anchoring IP address within the access network using IP-in-IP tunneling.

 draft-bernardos-dmm-cmip-01
 draft-bernardos-dmm-pmip-03
 draft-bernardos-dmm-distributed-anchoring-04
 draft-chan-dmm-enhanced-mobility-anchoring-00
 draft-sarikaya-dmm-for-wifi-00.txt
 draft-seite-dmm-dma-07.txt
 draft-xuan-dmm-nemo-dmm-02.txt
 draft-korhonen-dmm-local-prefix-01

 The need for this category is well-understood. The challenge is having
 plethora of solutions. Though the main concept is common…


 *5. Corresponding node/network anchoring*


 Still under Enhanced mobility anchoring.

 Anchoring IP address on the Corresponding Node or Corresponding Network.

 Mobile IPv6 route optimization
 draft-yegin-dmm-cnet-homing-02
 draft-xiong-dmm-ip-reachability-01
 draft-templin-aerolink-29

 This category of solutions are also needed (for their ability to produce
 better paths and different applicability with respect to the Category 4)


 *6. Host-route based intra-domain solutions*


 Forwarding path and signalling management

 Non-tunneling solutions.

 draft-chan-dmm-enhanced-mobility-anchoring-00
 draft-matsushima-stateless-uplane-vepc-02
 draft-mccann-dmm-flatarch-00
 draft-sarikaya-dmm-for-wifi-00.txt

 Solutions in this category are competing with the Category 4 type
 solutions. There are various pros and cons. IMHO, we cannot resolve that
 contest, hence we should produce solution for both categories and let
 the industry pick and choose. Given that these solutions are isolated
 from the other components (categories), standardizing both should not
 have adverse impact on the 

Re: [DMM] WG adoption (was Re: DMM solution space)

[Behcet Sarikaya]

Hi Alper,

draft-sarikaya-dmm-for-wifi-
00.txt does not use anchoring, I don't know how many times I should tell?

It simply extends vEPC, so it should be classified wherever vEPC is
classified, and I don't care where.

Regards,

Behcet

On Thu, Jul 17, 2014 at 2:45 PM, Alper Yegin alper.ye...@yegin.org wrote:

 On Jul 17, 2014, at 9:11 PM, Sri Gundavelli (sgundave) wrote:

 I'm in favor of this approach. This was my suggestion as well in the past
 (when we presented prefix coloring spec) to move forward some documents.
 But, those should be documents which are considered common across multiple
 solution approaches.


 Obviously. And that's the case in this particular instance.

 Recapping the DMM solution space analysis below.


 Per-flow IP address configuration according to mobility needs

 Apps indicating their mobility needs to the IP stack on the MN, and
 associated IP configuration signaling between the MN and the network.

 draft-bhandari-dhc-class-based-prefix-03
 draft-korhonen-dmm-prefix-properties-00.txt
 draft-yegin-dmm-ondemand-mobility-02

 Mobility solution selection

 MN determining the type of mobility solution(s) it'd apply to a given flow.

 draft-yegin-ip-mobility-orchestrator-00

 IP anchor selection

 MN selecting the IP anchor node after it decides to use IP anchoring
 (whether in the access network or the core network).

 draft-aliahmad-dmm-anchor-selection-00.txt


 Access network anchoring

 Anchoring IP address within the access network using IP-in-IP tunneling.

 draft-bernardos-dmm-cmip-01
 draft-bernardos-dmm-pmip-03
 draft-bernardos-dmm-distributed-anchoring-04
 draft-chan-dmm-enhanced-mobility-anchoring-00
 draft-sarikaya-dmm-for-wifi-00.txt
 draft-seite-dmm-dma-07.txt
 draft-xuan-dmm-nemo-dmm-02.txt


 Corresponding node/network anchoring

 Anchoring IP address on the Corresponding Node or Corresponding Network.

 Mobile IPv6 route optimization
 draft-yegin-dmm-cnet-homing-02
 draft-xiong-dmm-ip-reachability-01

 Host-route based intra-domain solutions

 Non-tunneling solutions.

 draft-chan-dmm-enhanced-mobility-anchoring-00
 draft-matsushima-stateless-uplane-vepc-02
 draft-mccann-dmm-flatarch-00




 Alper



 The issue seems to be charter approval.




 Sri


 On 7/17/14 11:04 AM, Alper Yegin alper.ye...@yegin.org wrote:


 Why? Why not make technical progress at every opportunity?

 This extreme serialization and every step overly stretchingŠ. am I the

 only one having issue with the slow progress?


 Alper






 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM solution space

[Behcet Sarikaya]

Hi Alper,

Two comments:

1. I think you should include only the active contributions. This
might reduce your list quite a bit.

2. Please put draft-sarikaya-dmm-for-wifi-
00.txt
into non-tunneling solutions category.

Regards.

Behcet

On Sat, Jul 12, 2014 at 6:13 AM, Alper Yegin alper.ye...@yegin.org wrote:
 Folks,

 I went over the solutions and categorized them.

 I haven't covered all of the solutions (due to lack of time). For any I-D
 that is missing, please state the name and where you think it belongs to.

 When we agree with the categorization and the candidates for each, then we
 can proceed to discussing how we can converge.

 Note: Multiple I-Ds under each category may be complementary, competing, or
 orthogonal (e.g., due to different applicability). It's case by case.


 Cheers,



 - Per-flow IP address configuration according to mobility needs

 Apps indicating their mobility needs to the IP stack on the MN, and
 associated IP configuration signaling between the MN and the network.

 draft-bhandari-dhc-class-based-prefix-03
 draft-korhonen-dmm-prefix-properties-00.txt
 draft-yegin-dmm-ondemand-mobility-02

 - Mobility solution selection

 MN determining the type of mobility solution(s) it'd apply to a given flow.

 draft-yegin-ip-mobility-orchestrator-00

 - IP anchor selection

 MN selecting the IP anchor node after it decides to use IP anchoring
 (whether in the access network or the core network).

 draft-aliahmad-dmm-anchor-selection-00.txt


 - Access network anchoring

 Anchoring IP address within the access network using IP-in-IP tunneling.

 draft-bernardos-dmm-cmip-01
 draft-bernardos-dmm-pmip-03
 draft-bernardos-dmm-distributed-anchoring-04
 draft-chan-dmm-enhanced-mobility-anchoring-00
 draft-sarikaya-dmm-for-wifi-00.txt
 draft-seite-dmm-dma-07.txt
 draft-xuan-dmm-nemo-dmm-02.txt


 - Corresponding node/network anchoring

 Anchoring IP address on the Corresponding Node or Corresponding Network.

 Mobile IPv6 route optimization
 draft-yegin-dmm-cnet-homing-02
 draft-xiong-dmm-ip-reachability-01

 - Host-route based intra-domain solutions

 Non-tunneling solutions.

 draft-chan-dmm-enhanced-mobility-anchoring-00
 draft-matsushima-stateless-uplane-vepc-02
 draft-mccann-dmm-flatarch-00



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Dime] Important dates - IETF90 getting close

[Behcet Sarikaya]

Hi Jouni,

Can you please add a slot for our draft
draft-sarikaya-dmm-for-wifi-00.txt into the agenda?

Thanks,

Behcet

On Wed, Jun 18, 2014 at 1:42 AM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 Folks,

 Just to remind you..

 4 July: Internet Draft submission - both -00 and revisions.

 7 July: WG chairs upload WG agendas.

 11 July: Early Bird registration and payment cut-off; the cost to
 register goes up.

 18 July: Last day to pre-register and pre-pay.

 20-25 July:  90th IETF Meeting in Toronto, ON, Canada.
 We have requested one meeting slots.

 ___
 DiME mailing list
 d...@ietf.org
 https://www.ietf.org/mailman/listinfo/dime

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: IETF 90 Preliminary Agenda

[Behcet Sarikaya]

Friday (after)noon session :)

On Mon, Jun 23, 2014 at 4:01 PM, Alper Yegin alper.ye...@yegin.org wrote:
 Oops, I missed the second one :-)
 Sorry for the false alarm.

 On Jun 23, 2014, at 11:15 PM, h chan wrote:

 I see 2 sessions in the agenda.

 H Anthony Chan

 From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin
 Sent: Monday, June 23, 2014 2:26 PM
 To: dmm@ietf.org
 Subject: [DMM] Fwd: IETF 90 Preliminary Agenda


 How are we going to make progress on solution discussions when all we have
 is a single 2-hr session for the whole DMM WG?


 Begin forwarded message:


 From: IETF Agenda age...@ietf.org
 Subject: IETF 90 Preliminary Agenda
 Date: June 23, 2014 10:16:20 PM GMT+03:00
 To: IETF Announcement List ietf-annou...@ietf.org
 Cc: i...@ietf.org
 Reply-To: i...@ietf.org, IETF Agenda age...@ietf.org



 The IETF 90 Preliminary Agenda has been posted. The final agenda will be
 published on Friday, June 27th, 2014. Currently Registration and Breaks are
 not displaying. This will be remedied on the final agenda.

 https://datatracker.ietf.org/meeting/90/agenda.html
 https://datatracker.ietf.org/meeting/90/agenda.txt

 More information regarding IETF 90 in Toronto, ON, Canada is located
 here:https://www.ietf.org/meeting/90/index.html

 Thank you!

 IETF Secretariat



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] draft charter text updates in github..

[Behcet Sarikaya]

Hi Fred,

Thanks for clarifying.

We can maybe add your solution to the bunch classified as Mobile IP
based approach, even though it does not require client software in the
MN.
We have a PMIP based solution and a routing based solution.
All of these I think, form a good basis to work on in dmm.

My 2 cents.

Regards,

Behcet

On Thu, Jun 19, 2014 at 6:13 PM, Templin, Fred L
fred.l.temp...@boeing.com wrote:
 Hi Behcet,

 -Original Message-
 From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
 Sent: Thursday, June 19, 2014 3:57 PM
 To: Templin, Fred L
 Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org
 Subject: Re: [DMM] draft charter text updates in github..

 I thought you said in your presentation that this draft is being
 AD-sponsored or going thru ISE?

 I think maybe you are talking about RFC6706, which was AD sponsored.
 The (bis) has not been picked up by an AD sponsor nor a working group
 yet, and is IMHO too far along in its evolution to fall back and take
 it down the ISE path now. So, wg item would seem like a suitable path.

 Thanks - Fred
 fred.l.temp...@boeing.com

 Regards,

 Behcet

 On Thu, Jun 19, 2014 at 4:20 PM, Templin, Fred L
 fred.l.temp...@boeing.com wrote:
  Hi Behcet,
 
  -Original Message-
  From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
  Sent: Thursday, June 19, 2014 2:08 PM
  To: Templin, Fred L
  Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org
  Subject: Re: [DMM] draft charter text updates in github..
 
  Isn't AERO becoming an RFC already?
 
  We already have RFC6706 as an experimental RFC, but I am working
  on a (bis) that will obsolete that:
 
  https://datatracker.ietf.org/doc/draft-templin-aerolink/
 
  The (bis) does not currently have a wg home, so I thought I would
  check to see if dmm would be a good home for it.
 
  Thanks - Fred
  fred.l.temp...@boeing.com
 
  Regards,
 
  Behcet
 
  On Thu, Jun 19, 2014 at 3:53 PM, Templin, Fred L
  fred.l.temp...@boeing.com wrote:
   Hi Sri,
  
   -Original Message-
   From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
   Sent: Thursday, June 19, 2014 1:40 PM
   To: Templin, Fred L; Brian Haberman; dmm@ietf.org
   Subject: Re: [DMM] draft charter text updates in github..
  
   Hi Fred,
  
Or, have IPv4 built-in from the onset for free; wouldn't that be 
better?
  
   Cannot say without understanding the solution approach and the needed
   effort. But, I guess with AERO, you have some effort in mind.
  
   I have code that, while not pretty, is astonishingly simple.
   I should be able to release that very soon.
  
   Thanks - Fred
   fred.l.temp...@boeing.com
  
   Any case, its WG/Chairs/AD call, but works for me.
  
  
   Regards
   Sri
  
  
   On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com 
   wrote:
  
   Hi Sri,
   
-Original Message-
From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Thursday, June 19, 2014 1:32 PM
To: Templin, Fred L; Brian Haberman; dmm@ietf.org
Subject: Re: [DMM] draft charter text updates in github..
   
Hi Fred,
   
Ack on the AERO capability.
   
   OK.
   
I have come to the conclusion that I have to deal with IPv4 for the 
rest
of my career (assuming some left). Surely, some day in 2016 is not 
some
thing that I'm looking at. My point is to limit the solution scope 
and
   if
it happens that DMM solution is immensely successful, we can 
introduce
IPv4 interfaces in phases.
   
   Or, have IPv4 built-in from the onset for free; wouldn't that
   be better?
   
   Thanks - Fred
   fred.l.temp...@boeing.com
   
Regards
Sri
   
   
   
   
   
   
   
   
   
On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com
   wrote:
   
Hi Sri,

I will just repeat that AERO works equally well on IPv4-only, 
IPv6-only
and dual-stacked access networks. This means that it can address 
real
world use cases today that cannot be addressed by other mechanisms.

As to schedule, who can truly say when IPv4 will be totally gone 
from
all access networks? 2016 is just a date on a calendar; we have 
been
waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT
it still hasn't happened.

Thanks - Fred
fred.l.temp...@boeing.com

 -Original Message-
 From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
 Sent: Thursday, June 19, 2014 12:33 PM
 To: Templin, Fred L; Brian Haberman; dmm@ietf.org
 Subject: Re: [DMM] draft charter text updates in github..

 Hi Fred,

 The DMM WG is still discussing PS and the related issues. By the
   time we
 adopt a solution and complete the work, we will surely be in 
 2016.
   So,
is
 it not safer to raise the bar and limit certain interfaces to
   IPv6-only
?
 I'm not arguing against adding any support for IPv4, but IMO the 
 bar
 should

Re: [DMM] Toronto DMM discussions

[Behcet Sarikaya]

I don't agree. Having two sessions is going to take us away from some
other sessions and it is going to increase the conflicts in our
schedule, etc.

Why don't we use dmm list rather than listing 17 or so names?

Behcet

On Fri, Jun 20, 2014 at 3:07 AM, Kostas Pentikousis
k.pentikou...@eict.de wrote:
 Hi all,

 I second‎ Albert on asking for 2 slots. One can focus on the charter and 
 finalizing agreement so we can move on in concert, and the second can be used 
 for the solution presentation plus discussion.

 Best regards - - Kostas
   Original Message
 From: Alper Yegin
 Sent: Freitag, 20. Juni 2014 09:53
 To: Jouni Korhonen; Dapeng Liu
 Cc: Hidetoshi Yokota; Sri Gundavelli; Behcet Sarikaya; 
 karag...@cs.utwente.nl; Kostas Pentikousis; Marco Liebsch; Peter McCann; h 
 chan; Ryuji Wakikawa; Juan Carlos Zuniga; Carlos Jesús Bernardos Cano; Suresh 
 Krishnan; pierrick.se...@orange.com IMT/OLN; Charlie Perkins; Danny Moses; 
 Jungshin Park; John Kaippallimalil
 Subject: Toronto DMM discussions


 Hello DMM chairs, folks,

 What is the plan for the IETF Toronto meeting?

 We'd finalize the new charter and seek (and get?) AD approval?

 Also, on the solution discussions front, can we make significant progress?
 I hope chairs have already requested two full slots. We really need to have a 
 big bandwidth for discussions.

 One idea could be:
 - Let all active solutions present, briefly.
 - Seek input from WG members during the presentations (maybe not have a 
 bidirectional discussion, as time may not permit. Instead, let the presenters 
 and WG members collect all the input)
 - Have a discussion about how to deal with the plethora of solutions on the 
 table. Decide on a structure to make progress.

 Especially the third item may go over time (beyond 2 meeting slots).
 In order to deal with that, let's also have an extension meeting. Like the 
 unofficial Bar Bof people do -- reserve a meeting room. Let's fix the date on 
 that extension meeting as soon as IETF agenda is out.

 ….

 What do you guys think?

 Alper






___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] draft charter text updates in github..

[Behcet Sarikaya]

I thought you said in your presentation that this draft is being
AD-sponsored or going thru ISE?

Regards,

Behcet

On Thu, Jun 19, 2014 at 4:20 PM, Templin, Fred L
fred.l.temp...@boeing.com wrote:
 Hi Behcet,

 -Original Message-
 From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
 Sent: Thursday, June 19, 2014 2:08 PM
 To: Templin, Fred L
 Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org
 Subject: Re: [DMM] draft charter text updates in github..

 Isn't AERO becoming an RFC already?

 We already have RFC6706 as an experimental RFC, but I am working
 on a (bis) that will obsolete that:

 https://datatracker.ietf.org/doc/draft-templin-aerolink/

 The (bis) does not currently have a wg home, so I thought I would
 check to see if dmm would be a good home for it.

 Thanks - Fred
 fred.l.temp...@boeing.com

 Regards,

 Behcet

 On Thu, Jun 19, 2014 at 3:53 PM, Templin, Fred L
 fred.l.temp...@boeing.com wrote:
  Hi Sri,
 
  -Original Message-
  From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
  Sent: Thursday, June 19, 2014 1:40 PM
  To: Templin, Fred L; Brian Haberman; dmm@ietf.org
  Subject: Re: [DMM] draft charter text updates in github..
 
  Hi Fred,
 
   Or, have IPv4 built-in from the onset for free; wouldn't that be better?
 
  Cannot say without understanding the solution approach and the needed
  effort. But, I guess with AERO, you have some effort in mind.
 
  I have code that, while not pretty, is astonishingly simple.
  I should be able to release that very soon.
 
  Thanks - Fred
  fred.l.temp...@boeing.com
 
  Any case, its WG/Chairs/AD call, but works for me.
 
 
  Regards
  Sri
 
 
  On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote:
 
  Hi Sri,
  
   -Original Message-
   From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
   Sent: Thursday, June 19, 2014 1:32 PM
   To: Templin, Fred L; Brian Haberman; dmm@ietf.org
   Subject: Re: [DMM] draft charter text updates in github..
  
   Hi Fred,
  
   Ack on the AERO capability.
  
  OK.
  
   I have come to the conclusion that I have to deal with IPv4 for the 
   rest
   of my career (assuming some left). Surely, some day in 2016 is not some
   thing that I'm looking at. My point is to limit the solution scope and
  if
   it happens that DMM solution is immensely successful, we can introduce
   IPv4 interfaces in phases.
  
  Or, have IPv4 built-in from the onset for free; wouldn't that
  be better?
  
  Thanks - Fred
  fred.l.temp...@boeing.com
  
   Regards
   Sri
  
  
  
  
  
  
  
  
  
   On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com
  wrote:
  
   Hi Sri,
   
   I will just repeat that AERO works equally well on IPv4-only, 
   IPv6-only
   and dual-stacked access networks. This means that it can address real
   world use cases today that cannot be addressed by other mechanisms.
   
   As to schedule, who can truly say when IPv4 will be totally gone from
   all access networks? 2016 is just a date on a calendar; we have been
   waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT
   it still hasn't happened.
   
   Thanks - Fred
   fred.l.temp...@boeing.com
   
-Original Message-
From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Thursday, June 19, 2014 12:33 PM
To: Templin, Fred L; Brian Haberman; dmm@ietf.org
Subject: Re: [DMM] draft charter text updates in github..
   
Hi Fred,
   
The DMM WG is still discussing PS and the related issues. By the
  time we
adopt a solution and complete the work, we will surely be in 2016.
  So,
   is
it not safer to raise the bar and limit certain interfaces to
  IPv6-only
   ?
I'm not arguing against adding any support for IPv4, but IMO the bar
should be high. We can certainly support all possible types of
  networks,
IPv4-only transport, IPv4-only user plane, and IPv4-only services.
  But,
looking at our current pace and doing some extrapolation, its safe 
to
   say
we will bake this for a long time and so limiting the work scope IMO
helps. But, this is just my opinion/comment and personally don't
  care if
some one wants to do the work and the chairs/AD/WG agree with it.
  Also,
   I
do not know yet how much of the solution work will really be
  IP-version
dependent. Mostly some network interfaces and there IPv6 possibly is
  a
safe assumption.
   
   
Regards
Sri
   
   
   
   
   
   
On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com
   wrote:
   
Hi Sri,

 -Original Message-
 From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri
  Gundavelli
(sgundave)
 Sent: Thursday, June 19, 2014 11:20 AM
 To: Brian Haberman; dmm@ietf.org
 Subject: Re: [DMM] draft charter text updates in github..

 Agree. We should ensure the base solution supports IPv6 transport
  and
user
 sessions. Optionally, support for IPv4 can

Re: [DMM] draft charter text updates in github..

[Behcet Sarikaya]

I don't understand why anchoring, re-anchoring are still in the charter.
There is no need for these terms.
We need to use general approaches in the charter such as routing,
network-based, client-based.

We also need to acknowledge the fact that almost all carriers will
have cloud networks by the time dmm picks up, if any. So the charter
should be open to the terms like virtualization, cloud, type of
futuristic terminology rather than the sticky anchor terminology.

Regards,

Behcet

On Thu, Jun 12, 2014 at 3:39 AM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 Alper,

 6/12/2014 10:55 AM, Alper Yegin kirjoitti:

 Jouni,

 I think I can understand and follow now, after your explanation.
 I cannot say the same when reading the charter text.


 Right. Then we just need to tweak the text, since if you have issues to
 parse it the IESG will have double that.


 I'll let others speak up. If I'm the only one having difficulty parsing
 that part of the charter, then so be it.
 Btw, I'm not aware of any decision that the baseline protocol will be
 PMIP. CMIP is equally on the table.


 Sure. For the anchoring stuff that was kind of assumed to be PMIP though.

 - Jouni



 Alper


 On Jun 12, 2014, at 10:25 AM, Jouni wrote:

 Alper,

 The latter bullet (forwarding path etc) is imho clearly in your 3. choice
 below. It can also be 2. since it is not yet stated what is the baseline
 protocol. The protocol solution will then determine that. The former bullet
 (enhanced anchoring etc) is imho clearly your 2. more than 1. It could be
 also partly in 3. if non-PMIP stuff is needed for the overall solution.
 Anyway, the baseline protocol is known - PMIP, and the solution aims to
 distribution within PMIP's boundaries.

 What is unclear here?

 Jouni


 --
 Jouni Korhonen
 Broadcom

 (Sent from my mobile..)

 Alper Yegin alper.ye...@yegin.org kirjoitti 12.6.2014 kello 9.09:

 Jouni,

 Based on earlier discussions, and what you wrote below, there are 3
 distinct things:

 1. *MIP maintenance.

 Any bug fix or improvement not driven by DMM, but for the sake of
 maintaining the *MIP baseline protocols, are handled here.

 2. MIP-based DMM solutions.

 3. Non-MIP-based DMM solutions.

 I presume these 3 items map to the those two bullets in the charter.
 Right?
 I cannot clearly tell the mapping though.

 Alper





 On Jun 12, 2014, at 12:14 AM, Jouni wrote:

 Alper,

 On Jun 11, 2014, at 10:54 PM, Alper Yegin wrote:

 Hi Jouni,


   o Enhanced mobility anchoring: define protocol solutions for a
 gateway and
 mobility anchor assignment and mid-session mobility anchor
 switching
 that go beyond what has been, for example, described in RFC
 6097, 6463,
 and 5142. The solution should also define a mechanism for
 preserving
 ongoing mobility sessions in a single administrative or IGP
 routing
 domain, which would involve directing traffic towards the new
 anchor.

   o Forwarding path and signalling management: the mobility agent
 that handles
 the mobility signalling interacts with the network elements in
 the DMM network
 for managing the forwarding state associated with a mobile
 node's IP traffic.
 These two functions may or may not be collocated. Furthermore,
 the forwarding
 state may also be distributed into multiple network elements
 instead of a
 single anchor like network element. Define required protocol
 extensions to
 allow described forwarding path and signalling management.


 These above two seem inseparable.
 I recommend we list them as one item.


 Hrmph.. not sure I agree.

 (The separation was between anchor selection and data-path
 management signaling before. At that time, it was a clearer 
 separation. But
 even at that time I was suggesting combining the two items. In this 
 latest
 text, the separation got blurred. The title of the first item, along 
 with
 references to switching, preserving sessions, directing traffic 
 all
 point to the context of the second one…)


 I see your point/concern. Since I (personally) see the enhanced
 mobility anchoring more towards maintenance work, I am tempted to have 
 these
 two different milestones from the beginning. We could remove the last
 sentence of the anchoring milestone..


 So, what's called enhanced mobility anchoring refers to 'maintenance
 work', and


 It could, since we specifically point three PMIP RFCs on a related
 topic: daa daa on anchor selection, solution for redirect during session
 establishment and solution for anchor switch that does not address what
 happens to ongoing sessions. When you do better than those, you are
 approaching a solution that allows one to better distribute anchors. Still
 very PMIPish, though.

 Forwarding path and signaling management refers to 'new DMM
 solution'?


 Yes.. we specifically do not refer how and based on what to achieve
 that.


 I didn't get that from the text…


 So is the Forwarding path and signaling management intent unclear in
 DMM scope?

 In my 

Re: [DMM] rechartering

[Behcet Sarikaya]

About two months ago I had made this proposal

First cycle, select one from each category of solutions, client,
network based and routing based
Second cycle, select one from the selected ones as the dmm solution.

which still stands, I think.



On Thu, May 29, 2014 at 4:03 PM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 Bechet,

 5/29/2014 11:52 PM, Behcet Sarikaya kirjoitti:

 Hi Jouni,

 I was looking at the charter text and noticed one important issue. The
 charter seems to be stuck with the good old anchor think. Almost all
 text is about anchoring, anchor selection, anchor reselection, and so
 on.

 However in the past several months, we have seen in Alper's events,
 presentations which seem to have no anchor.

 I don't see any active draft that talks about the anchors.

 In view of this, my question is how are we going to go ahead with this
 charter and meet the deadlines?


 I (myself) see still value dragging along some anchoring stuff just to allow
 smoother migration from current deployed models toward less centralized
 architectures.

 But you are right that we should not get stuck on those.. and that has not
 been the intent either.


 Or else, are we better off with a charter text which is much less
 dependent on the anchors, something  which could make it possible to
 progress one of those proposals??


 You are welcome to propose concrete text  change snippets to the current
 charter text.

 - Jouni



 Regards,

 Behcet


 On Tue, May 27, 2014 at 3:50 AM, Jouni Korhonen jouni.nos...@gmail.com
 wrote:


 Now that the gap analysis I-D is almost on the stage of leaving the WG
 and
 the requirements I-D has almost completed IESG, it would be time to
 return
 to the rechartering topic.

 First, the latest revision can be found at:
 https://github.com/jounikor/dmm-re-charter

 Second, have a look at it. There are few changes proposed by Alper eons
 ago
 and corrected milestones pointed by Behcet.

 Third, let us get this finally done..

 - Jouni

 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti:

 Folks,

 Sorry for letting this topic to rot in a dark for the couple of last
 weeks. I'll crank out a revision shortly..

 - Jouni  Dapeng



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02

[Behcet Sarikaya]

Hi Satoru,

Thanks again.

Please see my replies inline.

Regards,

Behcet

On Tue, May 20, 2014 at 8:47 PM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
 Hi Behcet,


 On Wed, May 21, 2014 at 1:17 AM, Behcet Sarikaya sarikaya2...@gmail.com
 wrote:
 -- snip --


 
  Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I
  guess BGP Route Update) is initiated by
  which node and is going to which node?
 
  As you see step 14 in the sequence, any specific node aren't assumed to
  initiate routing update on vEPC side, due to the scope of the draft,
  EPC-E
  router is the receiving node of routing update

 You mean more than one node can initiate it, my question was which
 node(s)?


 I meant that the draft doesn't mention exactly which node advertise that, it
 could be expected to exist in the vEPC side. But I find that in terms of
 usual BGP operation, that node could be Route-Reflector(RR), or
 Route-Server(RS).
 Just one case would be expected that a set of information which includes an
 endpoint information of tunnel and an UE assigned prefix is informed from a
 mobility management node in the vEPC to RR or RS.


Are you sure?
How would RR or RS know about UE mobility?

I was expecting you to say MME?



 
  In Step 15 you have EPC-E initiating this and it is going towards RTR.
  Why
  is this not sufficient? i.e. since EPC-E
  can detect mobility?
  Why do you need Step 14?
 
  The reason of the EPC-E advertise route toward RTR is that EPC-E can
  aggregate multiple UE's prefixes into less BGP routes as a part of
  normal
  routing operation within operator's network.

 You mean host routes are not needed in the upstream BGP routers? How
 does that work?


 Yes, host routes are not needed in the upstream routers because aggregated
 routes EPC-E router advertised work well for the upstream routers to send
 out packets toward advertising EPC-E routers.


Isn't it kind of host routes? Maybe host prefixes? Otherwise I can not
image how you would route to UEs that are topologically incorrect?




 Step 14 makes EPC-E not to
  detect mobility directly.

 I understand that.

 
  For the uplink traffic from UE, you seem to assume that it is always
  towards RTR. Could it not be directed to
  another UE? What happens in that case?
 
  When an EPC-E router has a route for destination of the packet from UE,
  the
  EPC-E router forward the packet to the destination.

 You mean to another EPC-E?


 I just meant that the packets are always forwarded along with the routing
 table of each node.


Yes, I think that the packet to another UE would be routed downstream
before reaching the RTR.

 cheers,
 --satoru

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02

[Behcet Sarikaya]

Hi Satoru,

Thanks for your reply.
My further comments are inline.

Regards,

Behcet

On Tue, May 20, 2014 at 1:06 AM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
 Hi Behcet,

 Sorry for my late response. Let me try to answer to your questions.

 Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I
 guess BGP Route Update) is initiated by
 which node and is going to which node?

 As you see step 14 in the sequence, any specific node aren't assumed to
 initiate routing update on vEPC side, due to the scope of the draft, EPC-E
 router is the receiving node of routing update

You mean more than one node can initiate it, my question was which node(s)?


 In Step 15 you have EPC-E initiating this and it is going towards RTR. Why
 is this not sufficient? i.e. since EPC-E
 can detect mobility?
 Why do you need Step 14?

 The reason of the EPC-E advertise route toward RTR is that EPC-E can
 aggregate multiple UE's prefixes into less BGP routes as a part of normal
 routing operation within operator's network.

You mean host routes are not needed in the upstream BGP routers? How
does that work?

Step 14 makes EPC-E not to
 detect mobility directly.

I understand that.


 For the uplink traffic from UE, you seem to assume that it is always
 towards RTR. Could it not be directed to
 another UE? What happens in that case?

 When an EPC-E router has a route for destination of the packet from UE, the
 EPC-E router forward the packet to the destination.

You mean to another EPC-E?

 Otherwise, the packet
 would be forwarded along with routing table of the router.

 You say that
 EPC-E supports the user
   plane functions of SGW and PGW.
 So there is no PGW in your design, I mean no anchor PGW?

 Yes, there're no entities of PGW and SGW in terms of user-plane. Also in the
 routing point of view, since a cluster of EPC-Es share same UE routes set,
 each of them can be an anchor.

 What happens to the control plane functions of SGW and PGW? Where are
 they?

 In terms of control-plane, they are expected to exist in the vEPC. You can
 see another benefit for that in section 4.2 of the draft.

 cheers,
 --satoru



 On Fri, May 9, 2014 at 6:25 AM, Behcet Sarikaya sarikaya2...@gmail.com
 wrote:

 Hi Matsushima-san,

 I have some other questions on your draft.

 Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I
 guess BGP Route Update) is initiated by which node and is going to which
 node?

 In Step 15 you have EPC-E initiating this and it is going towards RTR. Why
 is this not sufficient? i.e. since EPC-E can detect mobility?

 Why do you need Step 14?

 For the uplink traffic from UE, you seem to assume that it is always
 towards RTR. Could it not be directed to another UE? What happens in that
 case?

 You say that
 EPC-E supports the user
   plane functions of SGW and PGW.

 So there is no PGW in your design, I mean no anchor PGW?

 What happens to the control plane functions of SGW and PGW? Where are
 they?

 Regards,

 Behcet



___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02

[Behcet Sarikaya]

Hi Satoru,

I have a question about vEPC.

As the UE moves around its default router changes. Which node is the
default router? EPC-E?

Regards,

Behcet


On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima 
satoru.matsush...@gmail.com wrote:

 Peter,


 On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann peter.mcc...@huawei.comwrote:
 --snip--


  No, it isn't meant that specific routes to indicate each UEs prefix
  are advertised into the core.
  I'll try to improve that text in next revision of the draft.

 Yes please clarify because the current text seems to say that UE prefixes
 are advertised into the core.


 Yes, thanks.



  I agree with you if a EPC-E has whole UE specific routes that exceed
   its capacity, it doesn't scale, yes. In the recent presentation
  through the webex, Ryuji were trying to explain that it's not intended
 to do.
  Routes contained in EPC-E will be limited/partitioned by operators
  policy, such as region, service, population scale, etc.,

 I was a bit confused by the suggestion to partition by region, because
 there would be no mobility across regions if you partitioned in this way.
 That's because different regions would use different PDN prefixes.  But,
 I suppose it would be ok to do this if you didn't need to support UE
 mobility across regions (or if you used OTT mobility such as client MIP
 for those cases).


 Partitioned by region sounds like that each regional network is isolated
 so that they has no connectivity between them.
 But it is not what I meant. Although a PDN prefix would be partitioned by
 region, the networks doesn't really need to be isolated.
 For example, when all EPC-E routers have connectivity to reach all RAN
 nodes, it makes easy to provide mobility across regions.
 Do you think that describing in the draft this kind of networking concept
 would be helpful to make things clear?



   You seem to attempt to address this issue in Section 4.1 when you
 talk
  about multiple   sets of EPC-E devices, each one dedicated to a
 given
  geographic region.
 
 
  Ah, no. Sec 4.1 is intended to explain just scalability issue, and how
  to deal that issues with routing techniques in operation.

 Ok, I guess in the most common case you would have several slices of
 EPC-E, each set serving a different PDN prefix and a different set of UEs.
 There would be one EPC-E from each slice, each representing a partition of
 the PDN prefixes, at each EPC-E deployment site between eNBs and core.
 A given UE's current location would need to be BGP UPDATEd to each of the
 EPC-E in the slice that covered that UE's PDN prefix.


 In my mind, that sounds like when an operator assign a prefix to a PDN,
 the operator can divide the prefix into several longer prefixes. Each
 divided prefix, let's say sub-PDN prefix, may be allocated to a region,
 or any other operator's partition policy. It doesn't need to be assign a
 whole PDN prefix to a partition, or slice you said.




It seems to me that each set of EPC-E could cover no more than
 the
  scope covered by a singleSGW today, because they each have the same
  amount of state as an SGW. Essentially   you have described how to
 build
  a replicated SGW with failover to different nodesbased on the
  re-convergence of BGP after a failure (presumably you could get the
   core network to react to the closure of a BGP TCP session).  So I
 think
  this addresses   the problem of fault-tolerance that has been
 identified
  with the tunnel-based solutions, but not really the scalability
  bottleneck problem.
 
  The nature of BGP makes easy to do that. I think Sec 3.4 would be
  right place to explain that. But I couldn't see that flavor of text in
  sec 4.1. Would you point which text in Sec 4.1 makes you confuse?

 It was the text in the penultimate paragraph that talked about
 partitioning
 by region.  If you do that, there is no mobility across regions, right?


 As I mentioned before, mobility across regions is available.



 But if you partition by PDN prefix (sets of UEs) then you can have a whole
 stack of EPC-E at each deployment site, covering the entire population of
 UEs.

   In fact, if you consider mobility from one set to another, if
 you
  want to keep the
   UE's IP address, you would need to broadcast the same set of PDN
  prefixes from all
   sets of EPC-E.  In fact this would mean that all EPC-E throughout
 the
  network, even
   if they are in different sets, need to be prepared to handle
  packets for any UE
   and so they ALL would need the eNB F-TEIDs for ALL UEs.  Please
 tell
  me where I have
   made a mistake.
 
 
 
  No, an EPC-E just only receives packets from v6 core network toward
  UEs that routes installed into EPC-E. Because of that an EPC-E should
  advertise aggregated routes only for that includes its downstream UEs.
  When the EPC-E advertises whole routes to the core as you explained,
  yes I agree with you that won't be scalable. But it 

Re: [DMM] rechartering draft text updated

[Behcet Sarikaya]

Hi Jouni,


On Sun, Apr 6, 2014 at 3:45 AM, Jouni Korhonen jouni.nos...@gmail.comwrote:

 Alper,

 4/5/2014 2:24 PM, Alper Yegin kirjoitti:

  Hi Jouni,

 For the DMM solution, if we need extensions on the PMIPv6 or MIPv6, we'd
 do that -- naturally. I think this goes w/o saying. It's just part of the
 solution.
 And I now think the charter text does not aim that aspect.


 Right. Could be sloppy wording but if the DMM solution needs (P)MIPv6
 enhancements, those are in scope. They both have always been.


  I guess that PMIPv6 text is about maintenance of PMIPv6 outside the scope
 of DMM problem space.
 If PMIPv6 needs some extension that is not related to DMM, the place to
 do that in IETF would be the DMM WG.
 If so, OK, that's an extra, which I have no objection.


 This is correct, regarding the latest addition of maintenance text.


  I do not know specifically what we'd need to do on PMIPv6, or CMIPv6
 (outside the scope of DMM space).
 But I cannot imagine why we'd let PMIPv6 go in but exclude MIPv6.


 Ok. If you see it beneficial to add MIPv6 also into the maintenance part,
 then fine. Honestly, even if that gets mentioned there it is not to be
 considered and open invitation to work on client MIPv6 specific outside
 DMM scope topics just because it is in charter.


The issue here is in a routing based approach such as vEPC or the flat
architecture MIP6 extension  may come into picture, as Pete explained.
So it is not MIP6 extensions that MIP6 based DMM protocol needs which is in
charter's scope already.

I hope this clarifies.

Regards,

Behcet

 - Jouni



 Alper




 On Apr 4, 2014, at 11:06 PM, Jouni wrote:


 Alper,

 Thanks for the proposed text. I am not entirely sure about the addition
 of the client mobility. It was not discussed during the meeting when we
 were advised to add the maintenance part.

 What do the others think?

 - Jouni

 On Apr 4, 2014, at 3:47 PM, Alper Yegin wrote:

  Jouni,

 One more thing:

   The DMM working group will also work on maintenance-oriented and
   incremental extensions to the Proxy Mobile IPv6 protocol,
 specified
   in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily
   addresses any protocol gaps required to support existing
 deployments
   and other standards development organizations using the Proxy
 Mobile
   IPv6 protocol in their system architectures.

 We shall not shut the door on the client-based mobility.
 Hence, I propose the following revision:


   The DMM working group will also work on maintenance-oriented and
   incremental extensions to the Mobile IPv6 protocol, specified
   in RFC 5213, RFC 5844, and RFC 3775.


 I removed the last sentence because I wasn't sure if it really added
 any value.

 Alper






 On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote:

  Folks,

 Take a look at the latest revision. I have added the initial stab
 for the milestones. Comments and flames are welcome. If you want
 something to be changed, just propose text  diff. You might also
 want to say why the change is needed.

 https://github.com/jounikor/dmm-re-charter/blob/master/
 recharter_draft.txt

 - Jouni

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm





 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] rechartering draft comments

[Behcet Sarikaya]

Hi Jouni,

See inline.

On Thu, Mar 27, 2014 at 4:26 PM, Jouni Korhonen jouni.nos...@gmail.comwrote:

 Behcet,

 Thank you for constructive feedback. See inline.

 3/27/2014 9:51 PM, Behcet Sarikaya kirjoitti:

  |The DMM working group will also work on maintenance-oriented and
 | incremental extensions to the Proxy Mobile IPv6 protocol, specified
 | in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily
 |  addresses any protocol gaps required to support existing
 |deployments
  | and other standards development organizations using the Proxy
 |Mobile
 |  IPv6 protocol in their system architectures.


 Add Mobile IPv6 or remove the whole paragraph


 I see no point even trying to work on client mobile ipv6 enhancements..


3GPP may need it in the context of DSMIPv6, just like PMIPv6.



  |Enhanced gateway  mobility anchor selection and re-selection: define
 |   protocol solutions for a gateway and mobility anchor selection
 that
 |   go beyond what has been, for example, described in RFC 6097. |The
 |solution should also define a mechanism for anchor re-selection
 |that allow
  |   preserving ongoing mobility sessions in a single administrative
 |domain.

 Based on the above paragraph we have two charter items which basically
 make up the dmm solution.

 What is the justification? Is it RFC 6097 (no offense to you Jouni)?


 You know that it just happens to be the only RFC even attempting to explain
 how LMAs are selected dynamically. If the reference here is contentious, I
 am
 happy to remore it.. just give me alternative text.


  What about dmm solution that do not require any anchoring


 In scope and in the current text.


Where? I don't think any text counts as long as it is not in the milestones.



  What about SDN, NFV ideas that have been expressed by Dapeng and others?


 Not explicitly mentioned by those hype terms but not prohibited either
 in the charter text.


  Sorry but I don't see any enthusiasm on this charter draft in the WG.


 Then help bring in the enthusiams. The easiest way is to provide
 explicit text that we can then evaluate.


Let me bring back my proposal:

First cycle, select one from each category of solutions, client, network
based and routing based
Second cycle, select one from the selected ones as the dmm solution.

 Hope this helps to bring the enthusiasm we need :-)

Behcet

 - Jouni


 Behcet



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm



___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] rechartering draft text updated

[Behcet Sarikaya]

Hi Jouni,

Thanks for your hard work on the charter text.



On Wed, Mar 26, 2014 at 5:02 AM, Jouni Korhonen jouni.nos...@gmail.comwrote:

 Folks,

 Take a look at the latest revision. I have added the initial stab
 for the milestones. Comments and flames are welcome. If you want
 something to be changed, just propose text  diff. You might also
 want to say why the change is needed.


I don't understand why we have re-selection as a separate charter item?
Do you have an example document, draft which would qualify for this item?

I would also suggest taking currently available solution candidate, i.e.
vEPC draft and please tell us how that document fits into this charter?


Lastly, at the end of the charter a statement on rechartering or closing
down is needed for technical reasons, I think.

Regards,

Behcet


 https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt

 - Jouni

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex calls...

[Behcet Sarikaya]

Hi Alper,

I went to Doodle and noticed that the times have been arranged according to
non-North American audience.

Was this deliberate?

Regards,

Behcet


On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin alper.ye...@yegin.org wrote:


 Hello folks,

 Remember I was proposing to have conference calls for people to present
 their proposals and have discussions around them.
 Having more discussions would help us make better progress, not only
 within DMM or other WGs in IETF, but even in larger scale in the industry.

 Now I'm taking an initiative to start these calls

 The objective is to facilitate discussions around next generation mobility
 protocols and architectures.
 The scope is not limited to DMM. In other words, it is OK to discuss work
 that falls outside the scope of DMM (NETEXT, MIF, etc)
 Calls will be open to anyone. Feel free to forward this message to others...
 These will be only for informational discussions, we'll not be seeking any
 decisions...

 The idea is to provide sufficient time for people to explain their ideas
 properly, and others to have a chance to fully understand them and give
 feedback.

 ...

 We'll start with the presentation of vEPC from Ryuji.

 We determined 3 dates for this first call. Please go on the Doodle and
 register which one(s) work for you.
 Based on that we'll determine the Webex call date.

 http://doodle.com/y87dk2kpt8rcbwpz


 Make sure to enter your selections no later than the end of next Monday.


 Cheers,

 Alper



 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm