Diego Caviglia | 6 Dec 12:34 2005

Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus


Folks,
       a week has passed from the below e-mail, there has been only one
replay from a carrier the answers were for yes for both question 2 and 3.

Now I'll try to put the question in a different way.

Do anyone think that the ID should not be moved to WG status?

Regards

Diego

"Diego Caviglia" <Diego.Caviglia <at> marconi.com> <at> ops.ietf.org on 29/11/2005
08.08.59

Sent by:    owner-ccamp <at> ops.ietf.org

To:    ccamp <at> ops.ietf.org
cc:    "Dino Bramanti" <Dino.Bramanti <at> marconi.com>, "Dan Li <danli"

Subject:    Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus

Hi all,
           during the last IETF meeting unfortunaltely there was not enough
thime to present and discuss the ID in the subject, nevertheless I think
(but I'm an authour) the ID satisfy a real request from the Carries
community.

I'd like to ask you some questions
(Continue reading)

Adrian Farrel | 6 Dec 13:40 2005
Picon

Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus

Hi Diego,

Thanks for taking some of the burden of WG chair from my shoulders.

Before pushing this any further, I would be interested in your response to
the recent liaison from ITU-T SG15 (text below).

I would also like to understand whether this type of function is really
likely to be used repeatedly or whether we are describing a "one shot"
solution to an in-service upgrade.

Cheers,
Adrian
===
Text of liaison from SG15

At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that
CCAMP is discussing the issue of migration of connections under the
management plane to the control plane.  This topic has been discussed in
previous SG15 meetings and some of the conclusions are offered that may be
helpful to CCAMP.
The motivation for migrating calls and connections includes applying a
control plane to an existing transport network, and/or combining a
transport network whose connections are managed by an OSS and one whose
connections are established by a control plane.
Two broad issues with connection migration are dual views of a resource,
and the preconditions before protocol state is created for a connection.
Dual views of a resource concerns the need for a resource to be in both
management and control plane view the same time.  This is because although
the control plane may have responsibility of allocating/releasing
(Continue reading)

Loa Andersson | 6 Dec 14:19 2005
Picon

Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus

Diego,

why did this consensus call not come from the wg chairs. I'm
afraid that under the current circumstances you need to
interpret non-responsiveness as non-interest.

/Loa

Diego Caviglia wrote:
> Folks,
>        a week has passed from the below e-mail, there has been only one
> replay from a carrier the answers were for yes for both question 2 and 3.
> 
> Now I'll try to put the question in a different way.
> 
> Do anyone think that the ID should not be moved to WG status?
> 
> Regards
> 
> Diego
> 
> 
> 
> 
> 
> "Diego Caviglia" <Diego.Caviglia <at> marconi.com> <at> ops.ietf.org on 29/11/2005
> 08.08.59
> 
> Sent by:    owner-ccamp <at> ops.ietf.org
> 
(Continue reading)

Diego Caviglia | 6 Dec 14:32 2005

Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus


Hi Adrian,
           please find response/comments in line.

Regards

Diego

"Adrian Farrel" <adrian <at> olddog.co.uk> <at> ops.ietf.org on 06/12/2005 13.40.34

Please respond to "Adrian Farrel" <adrian <at> olddog.co.uk>

Sent by:    owner-ccamp <at> ops.ietf.org

To:    "ccamp" <ccamp <at> ops.ietf.org>, "Diego Caviglia"
       <Diego.Caviglia <at> marconi.com>
cc:

Subject:    Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus

Hi Diego,

Thanks for taking some of the burden of WG chair from my shoulders.
[dc] Ouch touched ;-) I apologize if I gave the impression of playing your
role, I was just trying to understand if there is interest in
this ID or not.

Before pushing this any further, I would be interested in your response to
the recent liaison from ITU-T SG15 (text below).
[dc] Ok I'll give an answer.
(Continue reading)

lidan 37133 | 7 Dec 15:05 2005

回复:Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus

Hi Adrian,

Please see my comments below.

Regards,

Dan Li

----- 原邮件 -----
从: Adrian Farrel <adrian <at> olddog.co.uk>
日期: 星期二, 十二月 6日, 2005 下午8:40
主题: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus

> Hi Diego,
> 
> Thanks for taking some of the burden of WG chair from my shoulders.
> 
> Before pushing this any further, I would be interested in your 
> response to
> the recent liaison from ITU-T SG15 (text below).
> 
> I would also like to understand whether this type of function is 
> reallylikely to be used repeatedly or whether we are describing a 
> "one shot"
> solution to an in-service upgrade.

MP2CP and CP2MP migration can be used for many scenarios, some cases are given 
here:
1) For control plane upgrade, after introduced the control plane, the services 
can be migrated from MP to CP.
(Continue reading)

Adrian Farrel | 7 Dec 21:46 2005
Picon

RFC 3946 bis

Hi Dimitri,

Since there has been no further comment on the list about this work, could
you:

- tidy up the draft (i.e. remove the editorial notes)
- update the "Note 3." text as we discussed
- re-submit

Once that is done, we will last call and move on.

Thanks,
Adrian

Adrian Farrel | 7 Dec 23:37 2005
Picon

Incoming liaisons from the ITU-T

Hi,

There were four liaison statements sent to CCAMP by the recent meeting of
Questions 12 and 14 of Study Group 15 of the ITU-T.

These can be seen at http://www.olddog.co.uk/incoming.htm or through the
IETF's liaison tracker pages.

The subjects were:
- Control plane resilience
- Connection migration
- ASON-related work
- ASON lexicography

The last two require a response from us by 27th January.

Thanks,
Adrian

Dimitri.Papadimitriou | 8 Dec 11:29 2005
Picon
Picon

Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus


hi adrian, diego, all

the scope of the mechanism should have been limited to create a control
plane state when the corr. data plane resources have already been
provisioned for the same connection by local config., MP, MPLS (for PSC
LSP), whatever ... all the specifics in terms of migration from MP to CP
and vice-versa are NOT to be standardized and falls outside the scope of
the GMPLS protocol work per se; on the other side, if we need to initiate a
work item on the migration to GMPLS *CONTROL PLANE* and come out with some
operational guidelines, i strongly recommended to link this work with the
item already started on this specific topic

note: each time we include a bit in the ADMIN_STATUS object that refers to
an operation which is not limited to a control plane related operation we
should not "standardize" that behaviour; reason is because jumping in the
bandwagon of standardizing usability and applications of the GMPLS control
plane mechanism has as many profiles as users (we have had the same
discussion during the p&r discussion loop); in the present case, we would
be in a situation where we would be std'ing the usability of a CP mechanism
assuming a that a) the MP <-> CP interaction is known (and hence also
std'ized ?) but in a case where the following config is to considered we
would also need to make assumptions about MP_1 <-> MP_2

MP_1 ---- MP_2
  |         |
CP_1 ---- CP_2

---

(Continue reading)

Internet-Drafts | 10 Dec 00:50 2005
Picon

I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: A Lexicography for the Interpretation of
                          Generalized Multiprotocol Label Switching 
                          (GMPLS) Terminology within The Context of the 
                          ITU-T's Automatically Switched Optical Network
                          (ASON) Architecture
	Author(s)	: I. Bryskin, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-ason-lexicography-04.txt
	Pages		: 17
	Date		: 2005-12-9
	
Generalized Multiprotocol Label Switching (GMPLS) has been developed
   by the IETF to facilitate the establishment of Label Switched Paths
   (LSPs) in a variety of data plane technologies and across several
   architectural models. The ITU-T has specified an architecture for
   the control of Automatically Switched Optical Networks (ASON).

   This document provides a lexicography for the interpretation of GMPLS
   terminology within the context of the ASON architecture.

   It is important to note that GMPLS is applicable in a wider set of
   contexts than just ASON. The definitions presented in this document
   do not provide exclusive or complete interpretations of GMPLS
   concepts. This document simply allows the GMPLS terms to be applied
   within the ASON context.

   It is important to note that GMPLS is applicable in a wider contexts
   than ASON. The definitions presented in this document do not provide
(Continue reading)

rfc-editor | 12 Dec 21:08 2005

RFC 4257 on Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks


A new Request for Comments is now available in online RFC libraries.

        RFC 4257

        Title:      Framework for Generalized Multi-Protocol Label
                    Switching (GMPLS)-based Control of Synchronous
                    Digital Hierarchy/Synchronous Optical Networking
                    (SDH/SONET) Networks
        Author(s):  G. Bernstein, E. Mannie, V. Sharma, E. Gray
        Status:     Informational
        Date:       December 2005
        Mailbox:    gregb <at> grotto-networking.com,
                    eric.mannie <at> perceval.net, v.sharma <at> ieee.org,
                    Eric.Gray <at> Marconi.com
        Pages:      35
        Characters: 86974
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ccamp-sdhsonet-control-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4257.txt

Generalized Multi-Protocol Label Switching (GMPLS) is a suite of
protocol extensions to MPLS to make it generally applicable, to
include, for example, control of non packet-based switching, and
particularly, optical switching.  One consideration is to use GMPLS
protocols to upgrade the control plane of optical transport networks.
This document illustrates this process by describing those extensions
to GMPLS protocols that are aimed at controlling Synchronous Digital
(Continue reading)


Gmane