Marco Liebsch | 21 Oct 21:58 2014
Picon

[FPSM] WT call#2

Folks,
as per the conclusion of first telco about Forwarding Path and Signaling Management (FPSM),
we considered to schedule a 2nd call before IETF91. Please fill the following doodle if you’re interested
in attending the call. Let’s see if we can bring most people together.  

 

http://doodle.com/pxairi9w9c6mgfb3

 

Best regards,

marco

 

--

 

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Brian Haberman | 21 Oct 19:25 2014
Picon

Fwd: New Liaison Statement, "Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)"

Something for you to be aware of...

Brian

-------- Original Message --------
Subject: New Liaison Statement, "Broadband Forum Work on “Hybrid Access
for Broadband Networks” (WT-348)"
Date: Tue, 21 Oct 2014 09:06:52 -0700
From: Liaison Statement Management Tool <lsmt@...>
To: The IETF Chair <chair@...>
CC: david.i.allan@..., sven.ooghe@...,
gbingham@...,
guiu.fabregas@..., The IESG
<iesg@...>, David Sinicrope <david.sinicrope@...>,
rmersh@..., david.j.thorne@...,
christophe.alter@...

Title: Broadband Forum Work on “Hybrid Access for Broadband Networks”
(WT-348)
Submission Date: 2014-10-21
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1355/

From: Broadband Forum (Christophe Alter <christophe.alter@...>)
To: The IETF (The IETF Chair <chair@...>)
Cc: The IESG <iesg@...>,David Sinicrope
<david.sinicrope@...>,christophe.alter@...,david.i.allan <at> ericsson.com,david.j.thorne@...,sven.ooghe@...,guiu.fabregas@...,rmersh@...,gbingham <at> broadband-forum.org
Response Contact:
Technical Contact:
Purpose: For information

Body: Dear IETF and 3GPP colleagues,

At the Broadband Forum Meeting held recently in Dublin, Ireland, the End
to End Architecture
Working Group has approved and begun work on a new project called
“WT-348 Hybrid Access for
Broadband Networks” defining architectural requirements to allow
coordinated and, when
needed, simultaneous use of fixed broadband access and 3GPP access
networks for
converged operators.

The business drivers for this work include enabling service providers to
offer faster service
provisioning and fulfillment, higher throughput and increased WAN
reliability.

We will keep you informed of this work as it progresses.

The Broadband Forum’s Q4 meeting will be held December 8 - 12, 2014 in
Taipei, Taiwan.

Sincerely,
Christophe Alter,
Broadband Forum Technical Committee Chair
Attachments:

    Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)

https://datatracker.ietf.org/documents/LIAISON/liaison-2014-10-21-broadband-forum-the-ietf-broadband-forum-work-on-hybrid-access-for-broadband-networks-wt-348-attachment-1.pdf

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Behcet Sarikaya | 20 Oct 20:16 2014
Picon

Re: AERO and Mobile IP comparison

 Hi Fred,

 I think your draft is now Rev. 44 at
https://tools.ietf.org/html/draft-templin-aerolink-44

I don't really have any comments on the text. But if you have been
wondering why AERO reminds people Mobile IP or Proxy Mobile IP or
MOBIKE?

I classify those protocols as 20th century protocols. It seems like
AERO is very much like them.

I think that in dmm maybe we should look into 21st century protocols.
That may mean designing with new concepts like
control plane/data plane separation,
virtualization, as in vEPC,
cloud,
and SDN control.

Regards,

Behcet
On Tue, Oct 7, 2014 at 4:20 PM, Templin, Fred L
<Fred.L.Templin@...> wrote:
> Hi Charlie,
>
>> -----Original Message-----
>> From: Charlie Perkins [mailto:charles.perkins@...]
>> Sent: Tuesday, October 07, 2014 1:25 PM
>> To: Templin, Fred L; dmm@...
>> Subject: Re: [DMM] AERO and Mobile IP comparison
>>
>> Hello Fred,
>>
>> A few little follow-up questions...
>>
>> On 10/7/2014 11:39 AM, Templin, Fred L wrote:
>> >> From: Charlie Perkins [mailto:charles.perkins@...]
>> >>
>> >> ...
>> >> This implies local-only mobility, right?
>> > Not just local, but global also. Take for example an AERO mobile router that is connecting
>> > over an access link provided by some ISP other than its home network. In that case, the
>> > node typically remains connected to its home link by setting up a VPN connection via a
>> > security gateway connected to its home network. In that case, the AERO link is said to
>> > be extended *through* the security gateway. So, the AERO mobile router remains
>> > tethered to its home link via the VPN, but  it can set up route optimization with Internet
>> > correspondents in a manner similar to MIPv6. In that case, communications with the
>> > Internet correspondent can bypass the home network.
>>
>> - Is the VPN setup part of AERO?
>
> The AERO Client requests a DHCPv6 Prefix Delegation as part of the VPN setup. The
> security gateway (acting as an AERO Server) delegates the prefix and sets up a
> neighbor cache entry for the Client.
>
>> - How does the mobile router know whether or not to do this?
>
> The AERO Client needs to know whether it is connecting to an access link provided by
> the home network or by an ISP outside of the home network. One way of doing this is
> to examine the connection-specific DNS suffix the Client gets when it connects to the
> access link and comparing it to the home network DNS suffix.
>
> When I think about my laptop computer user experience, I have to perform a manual
> intervention to select a security gateway and set up the VPN when I am connecting via
> an Internet access link. That would be OK and compatible with AERO as well, but would
> be much better if it were automated. Whether it can be fully automated depends on
> what kind of security credentials are necessary to establish the VPN, e.g., whether
> certificates alone are sufficient or whether some kind of active badge needs to be
> swiped, etc. Do you know more about this?
>
>> - Why would the external AERO servers admit traffic from the AERO client?
>
> The external AERO Servers are security gateways that also delegate AERO Client
> Prefixes (ACPs) to Clients using DHCPv6 PD. During PD, the Server performs an
> additional layer of authentication for the Client above and beyond what is done
> for establishing the VPN. So, the Server has a way of knowing that the Client is
> permitted to source packets from the delegated ACP.
>
>>      Or, is AERO completely out of the picture for external networks?
>
> External networks as in something that does not have hard perimeters with
> security gateways - maybe like a university campus network? I'll have to think
> more about that, but in that case there may need to be some other trust basis
> besides source address verification and IPsec tunnels. Any ideas?
>
>> - Is the route optimization simply a matter of VPN to the correspondent
>> node?
>
> VPN to the correspondent node (triggered by AERO mechanisms) is certainly
> a use case that we don't want to rule out.
>
>>      Or, did you mean to suggest use of the MIPv6 mechanisms?
>
> For communications with correspondents that do not require IPsec protection,
> the mechanism is the same as the MIPv6 Return Routability, only using IPv6
> ND messaging for signaling. Otherwise, I just studied the RR procedure in
> RFC6275 and pretty much borrowed what I saw there for AERO.
>
> Thanks - Fred
> fred.l.templin@...
>
>> Regards,
>> Charlie P.
>>
>
> _______________________________________________
> dmm mailing list
> dmm@...
> https://www.ietf.org/mailman/listinfo/dmm
The IESG | 20 Oct 18:35 2014
Picon

WG Action: Rechartered Distributed Mobility Management (dmm)

The Distributed Mobility Management (dmm) working group in the Internet
Area of the IETF has been rechartered. For additional information please
contact the Area Directors or the WG Chairs.

Distributed Mobility Management (dmm)
------------------------------------------------
Current Status: Active WG

Chairs:
  Dapeng Liu <liudapeng <at> chinamobile.com>
  Jouni Korhonen <jouni.nospam <at> gmail.com>

Assigned Area Director:
  Brian Haberman <brian <at> innovationslab.net>

Mailing list
  Address: dmm <at> 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 5555, 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 one or more documents 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 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.

      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. Possible new documents and
milestones must still fit into the overall DMM charter scope as outlined
above. 

Milestones:
  Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group
document.
  Feb 2015 - Submit 'Forwarding path and signaling management' as a
working group document.
  May 2015 - Submit 'Exposing mobility state to mobile nodes and network
nodes' as a working group document(s).
  Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG.
  Nov 2015 - Submit 'Forwarding path and signaling management' submitted
to the IESG.
  Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network
nodes' submitted to the IESG.

The IESG | 20 Oct 18:35 2014
Picon

WG Action: Rechartered Distributed Mobility Management (dmm)

The Distributed Mobility Management (dmm) working group in the Internet
Area of the IETF has been rechartered. For additional information please
contact the Area Directors or the WG Chairs.

Distributed Mobility Management (dmm)
------------------------------------------------
Current Status: Active WG

Chairs:
  Dapeng Liu <liudapeng@...>
  Jouni Korhonen <jouni.nospam@...>

Assigned Area Director:
  Brian Haberman <brian@...>

Mailing list
  Address: dmm@...
  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 5555, 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 one or more documents 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 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.

      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. Possible new documents and
milestones must still fit into the overall DMM charter scope as outlined
above. 

Milestones:
  Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group
document.
  Feb 2015 - Submit 'Forwarding path and signaling management' as a
working group document.
  May 2015 - Submit 'Exposing mobility state to mobile nodes and network
nodes' as a working group document(s).
  Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG.
  Nov 2015 - Submit 'Forwarding path and signaling management' submitted
to the IESG.
  Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network
nodes' submitted to the IESG.
h chan | 20 Oct 04:56 2014

enhanced anchor description

The following is an attempt to describe anchor (for dmm) for discussion.

 

Different proposed dmm solutions have used anchor.

 

The functions of an anchor common to these solutions are:

(1) advertise prefix/address of the MN

(2) allocate prefix/address of the MN

 

The functions used in some proposed dmm solutions but are not common to all of them are:

(1) packets to/from the MN traverse through.

Note: with multiple anchors using anycast address, a packet may or may not traverse any one of the anchors.

Note: with route optimization in the host-based MIP, the packet does not traverse the anchor any more. Yet the anchor does perform the above functions.

(2) indirection, e.g., tunneling

(3) information, e.g., binding HoA and CoA

(4) sends route update, e.g., using BGP

 

Methods to provide mobility support using anchor:

(1) indirection

(2) update routing tables

 

H Anthony Chan

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
h chan | 20 Oct 04:47 2014

FW: enhanced anchor teleconference - notes

 

The following attended the enhanced anchor team teleconference on Oct 10 at 7-8AM pacific time.

Satoru Matsushima, Fred Templin, Alper Yegin, Marco Liebsch, Kostas Pentikousis, Anthony Chan

 

Anthony (AC): Introduction: Different DMM solutions are using anchors. They are using different names for the anchor. While the names may be different, the description of what it does ought to have similarities among. It is therefore suggested to first ask what are the functions of anchor and try to identify what are common among them. We might be able to further categorize different mechanisms in using the anchor.

 

Alper (AY): Like it, define various attributes of anchors.

 

AC: Examples are: draft-seite-dmm-dma called it MAR (mobility capable access router), and the functions include forwarding by tunneling, allocating IP prefix/addr, Advertize prefix plus location update. draft-bernardos-dmm-pmip called it MAAR, and the functions include forwarding by tunneling, allocation IP prefix/address, prefix advertisement and location update (in conjunction with a centralized mobility database). There are several other examples.

 

AY: IP anchor is a functional entity which can be located everywhere: it allocates IP address, and it advertise prefixes. Another element of the anchor is host-specific forwarding entry.

 

Fred (FT): Do we assume a Mobile IP type of model? Can the anchor talk to MN, or can it talk to MAG?

 

AY: We have not talked about the distinction between network-based and host-based protocols yet.

 

Discussion agreed to include both network-based and host-based mobility.

 

FT: Then for host-based solution, the traffic in the case of route optimization (directly between MN and CN) does not traverse through the above anchor.

 

Marco (ML): There is also a Control-Plane anchor.

 

AY: True. Don’t enter the discussion of other WTs.

 

AC: This discussion so far lists both data plane function and control plane function.

 

AY: Ok, let’s recognize that there are so far two entities, Control and Data Plane. They may be collocated or separated.

 

Discussion agrees to separately list the functions in the data plane and those in the control plane. It enables separating data and control planes but it does not exclude the cases where they are combined as in the mobility protocols in the past.

 

AY: … routers have a specific name, e.g. deflector. Host specific forwarding entries.

 

(FT: has to leave)

 

..discussion about lose definition of anchor (entity applying flow/host policies for traffic), the model applies to any RO traffic case. Even endpoints can function as anchor (MIP6 RO).

 

ML: multiple anchors to be considered. MAG to even CN can anchor traffic in case of RO.

 

AY: Can do this, but that deviates from understanding so far.

 

AC: Another example of multiple anchors is in draft-matsushima-stateless-uplane-vepc .

 

Question on whether the traffic in this draft is symmetric or asymmetric (UL/DL)

 

AY: Discuss where such anchor function can be located. There can be multiple anchors, and not just a single anchor.

 

Discussion agrees that it is not necessary to have a single anchor for a given prefix. There may be multiple anchors for the same IP prefix (as in the case of anycast and in the case of BGP)  

 

AC: There is an information element such as binding or a mobility database and with location update function in the control plane.

 

AY: That is the forwarding entry.

 

Discussions: It appears that the terms IP anchor and mobility anchor had been used, but they have remained undefined.

 

ML: anchor definition moves more towards legacy function of router/switch, which carries state for MN (per-host or aggregated).

 

AY: draft-mccann-dmm-flatarch uses BGP. More than one router can have a per-host state.

 

AC: Conclusion? Time schedule is tight. Charter requires to submit first draft in February.

 

AY: Let’s produce the WT output.

 

AC: We may start with the functions of the anchor. The next may be to explain the different ways of using the anchor to support mobility.

 

.. discuss

 

Discussion agrees that Discovery mechanism is in this WT. It means discover the identity of the anchor and its capabilities.

 

AC: It is desirable to categorize different mechanisms of using the anchor.

 

AY: There are 3 categories to locate the anchor, Anchoring in the MN’s access network, correspondent node’s network, and at the corresponding node itself.

 

AY: After discovery, there is signaling.

 

Notes taken by Marco, edited by Anthony.

 

H Anthony Chan

 

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Jouni Korhonen | 16 Oct 23:18 2014
Picon

Charter approved

Folks,

IESG has approved our new charter. Now we can execute at the full speed 
in the solution space!

- Jouni & Dapeng
Marco Liebsch | 15 Oct 15:41 2014
Picon

FPSM: Proposed agenda for tomorrow's WT call#1

Below you can find some proposed agenda items for tomorrow’s WT call on
Forwarding Path & Signaling Management (FPSM). For participation, please refer to
the WebEx details which Sri posted on the DMM mailing list some days ago.

 

Agenda WT call:

 

q  Check if everybody is on the same page w.r.t. objectives

q  Identify past/available work which falls into this work item

q  Technical summary and assessment of identified past/available work

q  Agree on next steps

q  Another WT telco before IETF91 ?!

 

Best regards,

marco

 

 

 

 

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Alper Yegin | 13 Oct 10:41 2014

Re: Mobility exposure & selection WT call

Folks,

See below for the webex call details.

Also, please note (and read!) the following background material:



Cheers,

Alper



Begin forwarded message:

From: Alper Yegin via Cisco WebEx <admin-tlbQiRySkngAvxtiuMwx3w@public.gmane.org>
Subject: Invitation to WebEx meeting: IETF DMM Mobility Exposure & Selection WT call
Date: October 13, 2014 11:29:07 AM GMT+03:00

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:
  
IETF DMM Mobility Exposure & Selection WT call
Thu, Oct 23, 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

This meeting does not have an agenda.
 

Access Information

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

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 237 930 353

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.

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


_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Sri Gundavelli (sgundave | 10 Oct 11:44 2014
Picon

Forwarding Path & Signaling Management - Work Team Call

When: Thursday, October 16, 2014 7:00 AM-8:30 AM. (UTC-08:00) Pacific Time (US & Canada)
Where: WebEx

*~*~*~*~*~*~*~*~*~*
> the clear winner for the telco date, where we should further investigate the DMM work item about forwarding path & signaling management, is as follows:
> Date: Thursday, 16th October 2014
> Time: 16:00 CEST / 07:00 PDT

On Marco's request, I'm setting up the WebEx.

Sri



-------------------------------------------------
Topic: DMM CP/DP Interface
Date: Thursday, October 16, 2014
Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 208 843 186
Password: dmm

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?MTID=m4d6ee51fed630b975258b4c1df68146f
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: dmm
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions that appear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.
Call-in toll number (US/Canada): +1-408-525-6800
Call-in toll-free number (US/Canada): +1-866-432-9903

Having trouble dialing in? Try these backup numbers:
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800

Access code:208 843 186
Global call-in numbers: https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=287922637&tollFree=1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf




CCP:+14085256800x208843186#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, 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 session. Please note that any such recordings may be subject to discovery in the event of litigation.
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm

Gmane