Jouni Korhonen | 22 Apr 14:55 2014
Picon

rechartering

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
internet | 18 Apr 18:06 2014
Picon

I-D Action: draft-ietf-dmm-requirements-16.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Distributed Mobility Management Working Group of the IETF.

        Title           : Requirements for Distributed Mobility Management
        Authors         : H Anthony Chan
                          Dapeng Liu
                          Pierrick Seite
                          Hidetoshi Yokota
                          Jouni Korhonen
	Filename        : draft-ietf-dmm-requirements-16.txt
	Pages           : 21
	Date            : 2014-04-18

Abstract:
   This document defines the requirements for Distributed Mobility
   Management (DMM) at the network layer.  The hierarchical structure in
   traditional wireless networks has led primarily to centrally deployed
   mobility anchors.  As some wireless networks are evolving away from
   the hierarchical structure, it can be useful to have a distributed
   model for mobility management in which traffic does not need to
   traverse centrally deployed mobility anchors far from the optimal
   route.  The motivation and the problems addressed by each requirement
   are also described.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dmm-requirements-16
(Continue reading)

Behcet Sarikaya | 17 Apr 23:57 2014
Picon

Re: Questions on draft-matsushima-stateless-uplane-vepc-02

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.matsushima <at> gmail.com> wrote:
Peter,


On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann <Peter.McCann-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
--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 single    SGW 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 nodes    based 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 would depend on
> EPC-E capacity and size of UE population in the network.

Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE
population, right?  There is no need to put all UEs on all EPC-Es.

Right.

cheers,
--satoru

_______________________________________________
dmm mailing list
dmm-EgrivxUAwEY@public.gmane.org
https://www.ietf.org/mailman/listinfo/dmm


_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Alper Yegin | 8 Apr 14:06 2014

Fwd: Invitation to WebEx meeting: Next-Gen Mobility Protocols and Architectures, Call #3

Folks,

See below for the details of the next call.

Cheers,

Alper


Begin forwarded message:


div,p,td,span{word-wrap:break-word; word-break:normal;} table{border-collapse:separate}
Hi,
 
Alper Yegin is inviting you to this WebEx meeting:
  
Next-Gen Mobility Protocols and Architectures, Call #3
Wed, Apr 16, 5:00 pm | 1 hr 30 min
Istanbul (Eastern Europe Summer Time, GMT+03:00)
Host: Alper Yegin
  
 
Add the attached iCalendar (.ics) file to your calendar.
 

Agenda

Fred presenting Transmission of IPv6 Packets over AERO Links.

http://www.ietf.org/id/draft-templin-aerolink-13.txt
 

Access Information

Where:   WebEx Online
Meeting number:   237 737 343
Password:   This meeting does not require a password.
 

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 237 737 343

Can't access your meeting? Get help.
Delivering the power of collaboration
Cisco WebEx Team
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the meeting to be recorded. By joining this meeting, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the meeting. Please note that any such recordings may be subject to discovery in the event of litigation.

©2013 Cisco and/or its affiliates. All rights reserved.
MT-A-001


_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Jouni Korhonen | 2 Apr 11:22 2014
Picon

WGLC #1 has ended for draft-ietf-dmm-best-practices-gap-analysis

Folks,

The WGLC #1 has ended. Thanks to Charlie for an extensive review. The 
sooner these nits gets addressed the sooner we can ship the document.

- Jouni

4/2/2014 12:16 PM, IETF Secretariat kirjoitti:
>
> The tags on draft-ietf-dmm-best-practices-gap-analysis have been changed
> by Jouni Korhonen:
> http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/
>
> Tag "Revised I-D Needed - Issue raised by WG" added.
> Tag "Other - see Comment Log" cleared.
>
>
> Comment:
> Charlie's comments
> http://www.ietf.org/mail-archive/web/dmm/current/msg01098.html
> http://www.ietf.org/mail-archive/web/dmm/current/msg01091.html
>
Alper Yegin | 1 Apr 08:22 2014

Fwd: Invitation to WebEx meeting: Next-Gen Mobility Protocols and Architectures (Call #2)

Folks,

Please see below for the details of the upcoming call (on Thursday).

Alper


Begin forwarded message:



div,p,td,span{word-wrap:break-word; word-break:normal;} table{border-collapse:separate}
Hi,
 
Alper Yegin is inviting you to this WebEx meeting:
  
Next-Gen Mobility Protocols and Architectures (Call #2)
Thu, Apr 3, 5:00 pm | 1 hr 30 min
Istanbul (Eastern Europe Summer Time, GMT+03:00)
Host: Alper Yegin
  
 
Add the attached iCalendar (.ics) file to your calendar.
 

Agenda

Pete presenting "Authentication and Mobility Management in a Flat Architecture"
http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00
 

Access Information

Where:   WebEx Online
Meeting number:   232 864 967
Password:   This meeting does not require a password.
 

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 232 864 967

Can't access your meeting? Get help.
Delivering the power of collaboration
Cisco WebEx Team
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the meeting to be recorded. By joining this meeting, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the meeting. Please note that any such recordings may be subject to discovery in the event of litigation.

©2013 Cisco and/or its affiliates. All rights reserved.
MT-A-001


_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Charles E. Perkins | 30 Mar 21:05 2014
Picon

[dmm] issue #46: rfcdiff output showing suggested editorial changes for draft-ietf-dmm-best-practices-gap-analysis-03.txt


Hello folks,

I made an editorial pass through 
draft-ietf-dmm-best-practices-gap-analysis-03
and used 'rfcdiff' to highlight the changes.  The 'rfcdiff' output is 
attached to
the ticket for issue #46.  It also includes an abbreviated list of the 
other issues
that I have already inserted onto the issue tracker.

I also uploaded the rfcdiff output to the IETF wiki page for [dmm].   
Here is the URL:

http://trac.tools.ietf.org/wg/dmm/trac/attachment/wiki/WikiStart/Diff%20%20draft-ietf-dmm-best-practices-gap-analysis-03.txt%20-%20draft-ietf-dmm-best-practices-gap-analysis-03cep-v2.txt.htm

When you see that web page, it probably looks like a raw .html file.  I 
don't
know how to fix that, but if you download the file and browse it, you should
see the rfcdiff output as it's supposed to look.

--

-- 
Regards,
Charlie P.
Peter McCann | 28 Mar 19:32 2014

Questions on draft-matsushima-stateless-uplane-vepc-02

Ryuji,

After viewing your slides from the presentation you did overnight (sorry I couldn't
be on the call) I went back and re-read the draft-matushima-stateless-uplane-vepc-02
draft.  I am still confused about a number of things:

You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going from the
EPC-E to the core network RTR, containing a Destination of UE-prefix and a Next-Hop
of EPC-E address.  However, in Section 3.4, you describe the RTR as knowing only the
PDN prefix, which is the same for all EPC-E, and the use of "hot-potato" routing to
deliver the packets to the nearest EPC-E no matter the UE destination IP address.

Which one is it?  Are the UE prefixes advertised into the core or not?

Assuming for now that the UE prefixes are not advertised into the core, but only the
PDN prefixes are advertised, then that means that every EPC-E must know about every
UE session, including the eNB F-TEID for every UE in the network, correct?  That's
because any one of them at any time could receive a packet for the UE from the core.
This doesn't seem scalable to me.

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.  It seems
to me that each "set" of EPC-E could cover no more than the scope covered by a single
SGW 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 nodes 
based 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.

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.

--
Peter J. McCann
Huawei Technologies (USA)
Peter.McCann@...
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA
Brian Haberman | 28 Mar 14:54 2014
Picon

IESG review of draft-ietf-dmm-requirements

All,
     The IESG discussed the requirements draft on its call yesterday.
There are a few items that need to be addressed in the document and a
larger, more educational, step that needs to be done prior to
publication.  There are two concrete changes needed in the document at
this time.  Barry Leiba raised the issue about the references to 3753,
5213, and 6275 should be normative.  Alia Atlas has asked that there be
some description of the applicability or deployment considerations
driving these requirements.  I think a good way to address this would be
to describe a common deployment model in use today and point out where
the requirements would lead to changes.  It may be useful to have
someone engage Alia on this topic.

      Another point raised, by Benoit Claise, is the OAM issue with
these requirements.  Benoit would either like to see OAM issues
discussed in the requirements document or in the new charter.  I think
that is a valid concern that the WG needs to discuss, specifically where
that need should be documented. As with the above, someone from DMM
should chat with Benoit if there are questions on what he would like to see.

     There are also a few good Comments raised by other ADs that should
be addressed.  Those can be seen on the document's ballot page:

https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements/ballot/

     The last issue raised, by Ted Lemon, is the architectural impact of
the mobility work.  He ties it to this document since he is fearful that
these requirements will lead to a solution that impacts the overall
Internet architecture.  To that end, I suggested that he invite several
DMM participants (I suggested the chairs) to participate in an upcoming
informal IESG call to discuss.  I suspect that Ted will hold this
document until that conversation occurs.

     Let me know if anyone has any questions on these points.

Regards,
Brian (your slightly frazzled AD)

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Jouni Korhonen | 28 Mar 06:44 2014
Picon

issues posted for dmm gap analysis

Folks,

Charlie made an extensive review of the gap analysis and posted
few issues. See then here;
http://tools.ietf.org/wg/dmm/trac/query?status=new&status=assigned&status=reopened&component=best-practices-gap-analysis

- JOuni
Alper Yegin | 27 Mar 22:57 2014

Next-Gen Mobility Protocols and Architectures Webex call #2

Folks,

The second call is for Pete to present http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00.

There are three candidate dates from next week. Please use the following doodle to mark the dates that work
for you.

http://doodle.com/um7cwnrk3ekid4pa

Doodle deadline is the end of next Monday (March 31).

Alper

Gmane