Subject: [mpls-tp] Question on draft-bhh-mpls-tp-oam-y1731-01.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 29 Mar 2009 07:14:44 +0000

Authors of draft-bhh-mpls-tp-oam-y1731-01.txt,

I read the draft and I have a question.

How do you see the deployment of your draft working?

draft-bhh-mpls-tp-oam-y1731-01.txt and by implication Y1731 OAM used for new
build MPLS-TP deployments?

The OAM of existing MPLS networks that evolve to MPLS-TP also evolving over
time to utilise draft-bhh-mpls-tp-oam-y1731-01.txt and by implication Y1731?

There being two parallel MPLS-TP OAM developments:
* one based on existing MPLS OAM message formats enhanced with additional
capabilities to meet the requirements of MPLS-TP
* one based on draft-bhh-mpls-tp-oam-y1731-01.txt and by implication Y1731

And the market ultimately decides which one (or both) prevails?

Etc.

Also I would request you remove section 5. We can debate the need for
interworking Ethernet & MPLS-TP OAM but even if the debate concludes we need
it I do not think this document is the place to specify it. I think if it is
to be specified it should be specified in its own dedicated document as it
is likely to have other implications and include material that is wider in
scope than draft-bhh-mpls-tp-oam-y1731-01.txt.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 30 Mar 2009 09:42:25 +0200

Ben,

See inlne... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: zondag 29 maart 2009 9:15
To: [email-masked]
Subject: [mpls-tp] Question on draft-bhh-mpls-tp-oam-y1731-01.txt

[mv] Y.1731 OAM PDUs extended with MPLS-TP headers (e.g. ACH) are used for
new build MPLS-TP deployments.

[mv] I do not know if MPLS networks with mp2p LSPs can and would evolve to
MPLS-TP with p2p LSPs.
     You indicated that your company will not evolve its MPLS network into
an MPLS-TP network.
     As I indicated in my earlier response to you, Y.1731 CCM and LBM/LBR
PDUs can be effectively
     deployed in MPLS networks that deploy a full mesh of mp2p LSPs. This
does not make the
     MPLS network a MPLS-TP network, but it emulates some of the MPLS-TP
capabilities
     (i.e. pro-active monitoring). 

[mv] I have got the feeling that a number of the requirements in the MPLS-TP
requirements draft
     do not belong there; expecially the associated bidirectional path
requirements seems to be
     inappropriate for MPLS-TP. It would be much better if we remove those
requirements from
     the MPLS-TP requirements draft and put those into a separate draft that
describes the
     requirements for emulation of some of the MPLS-TP capabilities on
non-MPLS-TP (i.e. MPLS)
     domains.

[mv] I assume that there are just two **proposals**, and that those
proposals will be 
     discussed in the coming period. Normal standards work should result in
the selection
     of one of the proposals and the implementation of this selected
proposal.

[mv] MPLS OAM is used in MPLS domains. With MPLS-TP being restricted to the
LSP and 
     Section layers, excluding the transport services layer, MPLS-TP domains
have 
     MPLS-TP LSPs which start/end at the edges of a MPLS-TP domain. The yet
undecided
     transport services layer signal will pass through those domains into
next domains.
     MPLS-TP LSP OAM will be bound to its MPLS-TP domain, similar to MPLS
LSP OAM which
     is bound to the MPLS domain.

[mv] MPLS and MPLS-TP domains are interconnected via the transport services
layer, which 
     is a client layer for both the MPLS and MPLS-TP domains. The best
transport services
     layer is the EVC layer. This layer is already present in the metro
ethernet networks
     and often also in the core networks.

Regards,
Maarten

Etc.

Ben

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 30 Mar 2009 10:33:48 +0200

Hello Ben,

> Authors of draft-bhh-mpls-tp-oam-y1731-01.txt,

See my reply in-line [hvh]

> I read the draft and I have a question.

[hvh] The slides presented in San Francisco on wednesday already
addressed some of your questions.
I hope they will be available soon on-line.

> How do you see the deployment of your draft working?

[hvh] MPLS-TP is designed for the transport network. It will be used
by service providers with a PTN.

> draft-bhh-mpls-tp-oam-y1731-01.txt and by implication Y1731 OAM used
> for new build MPLS-TP deployments?

[hvh] The service providers that need the same OAM capabilities
as provided by SDH/OTN and Carrier Ethernet.
Because they may already deploy Carrier Ethernet OAM tools (Y.1731) in
(part of) their network the tools from this draft will support them
in using the same tools in their MPLS-TP (part of) the network.

[hvh] This means the same tools and the same behaviour in their
whole PTN.

> The OAM of existing MPLS networks that evolve to MPLS-TP also
> evolving over time to utilise draft-bhh-mpls-tp-oam-y1731-01.txt and
> by implication Y1731?

[hvh] Yes, they will use the same tool set (or sub-set).
Because this toolset is already deployed in carrier Ethernet PTN
it has already been tested and interoperability between vendors
is proven.

> There being two parallel MPLS-TP OAM developments: * one based on
> existing MPLS OAM message formats enhanced with additional 
> capabilities to meet the requirements of MPLS-TP * one based on
> draft-bhh-mpls-tp-oam-y1731-01.txt and by implication Y1731

[hvh] Note that these are two drafts currently available.
The first proposing a new toolset and the second proposing to use
an existing toolset.

> And the market ultimately decides which one (or both) prevails?

[hvh] Please look at the list of co-authors of draft-bhh-mpls-tp-oam-y1731.

>  interworking Ethernet & MPLS-TP OAM but even if the debate concludes
> we need it I do not think this document is the place to specify it.

[hvh] I agree, and based on conversations we had in San Francisco we
decided to remove this section from draft-bhh-mpls-tp-oam-y1731.

> I think if it is to be specified it should be specified in its own
> dedicated document as it is likely to have other implications and
> include material that is wider in scope than
> draft-bhh-mpls-tp-oam-y1731-01.txt.

[hvh] See my comment above.

Cheers, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 30 Mar 2009 11:13:40 +0100

Maarten,

>      You indicated that your company will not evolve its MPLS network into

No I didn't. I said "I do not want to build an MPLS-TP network. I want to
use some MPLS-TP functionality in my existing deployed
boxes/implementations."

That is my definition of evolution - that the capabilities of my MPLS
network are enhanced to include those capabilities of MPLS-TP that I also
require.

Let's be clear. BT has spent the last 12 months deploying additional MPLS
capability to support Ethernet and other services. We now have a significant
deployed base of MPLS capability both within the UK and globally. We have
over 600 MPLS PoPs in the UK. We have over 200 MPLS PoPs outside the UK. Our
MPLS networks support a range of services including Ethernet, IP VPN, VPLS,
Studio and Broadcast quality television transmission, Voice, Broadband,
Internet etc.

It is not economically, commercially or strategically viable for us to
perform a parallel build of MPLS-TP at this time. If we are to make use of
the features of MPLS-TP we require then we must evolve our existing
installed base.

>      requirements for emulation of some of the MPLS-TP capabilities on

The Requirements document states:
   This work is based on two sources of requirements, MPLS and PWE3
   architectures as defined by IETF and packet transport networks as
   defined by ITU-T.  The requirements of MPLS-TP are provided below.
   The relevant functions of MPLS and PWE3 are included in MPLS-TP,
   except where explicitly excluded.

In the slides I have presented at IETF the last few meetings:
€Also includes some additions based on SP input
Additional requirements
Some requirements are stronger than stated by ITU-T
The authors do not believe there are any real conflicts between the ITU-T
requirements and the SP input.
€Therefore:
Requirements are a superset of ITU-T & SP requirements
Majority of the requirements come from ITU-T.

The requirements belong there. They are real SP requirements.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 30 Mar 2009 11:20:50 +0100

> [hvh] Please look at the list of co-authors of draft-bhh-mpls-tp-oam-y1731.

Huub, I am not sure I follow the point. You have SPs as co-authors, one may
infer that to mean they have requirements for this. That's fine. It does not
indicate a majority of a market.

Anyway, I was only trying to find out the how the authors saw the deployment
of the draft so I can think about how it may/may not fit with my
requirements. I have that now. Thanks.

Ben

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 30 Mar 2009 13:53:20 +0200

Hi Ben,

> indicate a majority of a market.

This draft is fully in line with the JWT agreement, see the slides:
http://www.ietf.org/MPLS-TP_overview-22.pdf
In particular the last bullet on slide 15.
Y.1731 is referenced on a few other slides as well.

Cheers, Huub.

---

From: <[email-masked]>
Date: Mon, 30 Mar 2009 13:52:10 +0100

Here are my views on this subject area Huub,
 
Huub wrote to Ben 30 March 2009 12:53

> Y.1731 is referenced on a few other slides as well.
I think there are at least 3 different issues all mixed-up in this
subject area, ie
-	peer-partition i/w
-	OAM functions
-	Artifically created OAM sublayer hierarchy.

These do not have to come as a lump-sum....and in a little more detail:

Peer-partition i/w.  Irrespective of whether OAM (or any DP/CP
functional component) is similar/same in 2 technologies, if either
technology is not top-of-stack then there is no technical case for their
peer interworking.  And speaking as an operator I do not want my
equipment suppliers wasting their/my time/money on unnecessary work.
Many things are possible, but some things are not sensible/useful....and
this is one of these.  

Note - There are important differences between the 3 network modes that
makes total DP/CP functional component alignment not possible.  However,
I do agree that we should try and re-use DP/CP components where it is
sensible.

Now I know you have indicated that section 5 will be removed from this
draft Huub, but I sincerely hope this issue will not re-surface in any
other draft.

I have no major problems with having the base OAM PDU structures defined
in Y.1731 as the target OAM for any co-ps mode network (not just
MPLS-TP). However, I do have some problems with some of the OAM concepts
that appear in Y.1731....for example:

-	I do not think having lots of nested TCM sublayers is a good
idea in general for OAM...even where the connectivity is at its most
static, ie at the bottom of stack transport co-cs mode networks, let
alone higher up the stack where connectivity is more dynamic.  Given
this is being discussed in IETF then before TCM is introduced into
MPLS-TP I would like to see some discussion of how this relates to TCM
in:
	o IP (v4 and v6)
	o co-cs networks using the GMPLS CP...since the GMPLS CP might
need to factor-in to TCM configuration act/deact.

I don't like TCM for several reasons, which include:

	* Concerns regarding the notion of multi-party ownership of
nested MEPs/MIPs....esp in networks that are not top of stack and should
not have E-NNIs between different parties in any case.

	* Concerns about the amount of configuration state required.  We
should be designing networks that have an intrinsically low defect
occurrence rate and therefore we should not be blanketing the network
with lots of a priori configured/nested TCM OAM state to catch rare
events....in other words the OAM philosophy here is wrong, and there are
smarter ways of passively tapping-off end-end CV/PM OAM flows at
intermediate nodes on the *rare* occasions one needs to carry-out more
detailed OAM investigation.  
	
	* There is a capex and opex cost associated with
providing/configuring/processing OAM....we should be quite conscious of
this fact.  In my experience Operations folks will turn off as much
'always on' OAM as they can....so providing over-complex OAM is almost
as bad as providing no OAM.

	* The OAM must be considerably more reliable than the network it
is monitoring and having lots of a priori configuration is at odds with
that goal IMO.  In particular the defect detection/handling OAM must be
as simple/sparse as possible....CV (carrying connection SA) and BDI is
all you really need here.

	* Before any TCM is defined it should be made quite clear how
this is dynamically handled across failure/recovery events.....and how
this is to be done in either the MP or the CP (hence my previous remark
that the GMPLS CP should consider TCM issues).  I do not believe any
nested TCM PM flows can be made accurate across such failure/recovery
events unless one forces pinch-points in the allowed routing
choice...see next item.

	* There should not be any artificial constraints on connection
routing choice by forcing intermediate pinch-points in the topology just
so that nested MEP/MIP configuration remains the same across
failures/recovery events....as doing this will reduce the network's
availability performance.

-	BDI piggybacking in CV is OK for symmetric p2p connections, but
this will need to be disabled on p2mp connections (root->leaf direction)

-	These days I am not convinced of the need for FDI/AIS in co-ps
mode networks.  AIS came from the 1970s PDH world and TTL logic which
floated to a logical 1 (+5V) on failure...so a binary all 1s signal was
the sensible 'dead' signature of a PDH layer network.....and crucially
it required no conscious effort to generate it.  In the cl-ps mode there
is no case for AIS/FDI whatsoever.....we don't have long-lasting
client/server 'connections' here like in the co-cs transport networks,
so it makes no sense to try and inject AIS/FDI into cl-ps mode clients.
Which is one reason IEEE threw out the notion of FDI/AIS in 802.1ag for
Ethernet (though it remains in Y.1731).  In the co-ps mode one has to
consciously generate FDI/AIS into client connections...so this is not
the same as the passive injection in the old co-cs case.  I am not
saying we should not do FDI/AIS in co-ps mode layer networks, but I am
saying I am not convinced it is that important (the alarm storm issue is
overplayed IMO).  Moreover if one does not create a load of nested TCM
sublayers in the first place then one does not need to worry about
injecting FDI/AIS into this artificial sublayered hierarchy (and
artificial alarm storms in such).

regards, Neil

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 30 Mar 2009 15:43:37 +0200

Hello Neil,

> Here are my views on this subject area Huub,

Please note that the subject is:
"Question on draft-bhh-mpls-tp-oam-y1731-01.txt"

> -	Artifically created OAM sublayer hierarchy.

You are changing the subject.

draft-bhh-mpls-tp-oam-y1731-01.txt describes a toolset
how and where these tools are deployed is outside the scope.

In a previous email I already mentioned that it is not
necessarily a 100% alignment with the PDUs defined in Y.1731,
so it could be a subset.

That is the reason to remove section 5.
I noticed that TCM is still (only) in the terminology section due
to a copy/paste mistake, so it will be removed and there is no
reason to discuss that in this subject.

Regards, Huub.

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 30 Mar 2009 10:03:39 -0400

Ben, colleagues,

I suggest adding two requirements to the MPLS-TP requirements document:

1. It must be possible for statically and dynamically provisioned/managed MPLS-TP LSPs to co-exist in the same layer network;

2. MPLS-TP Control Plane must provide a mechanism for MPLS-TP LSP dynamic ownership transfer from Management Plane to Control Plane and from Control Plane to Management Plane with 0 reconfigurations in the Data Plane.

The first requirement means, of course, that it must be possible for an MPLS-TP layer network operator to setup and manage some LSPs via Management Plane and some via Control Plane.

The second requirement means that it must be possible for the operator to statically provision an LSP and then have Control Plane to adopt the LSP (that is, create CP state for the LSP that already exists in the DP), so that form then on the LSP could managed (e.g. re-routed, modified, released, etc.) via Control Plane. Likewise, it must be possible for the operator to use Control Plane to dynamically setup an LSP, and once it is established have Control Plane to abandon the LSP, so that from then on it would be indistinguishable from the one that was statically setup.

Opinions?

Igor

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Mar 2009 15:23:35 +0100

> 1. It must be possible for statically and dynamically provisioned/managed MPLS-TP LSPs to co-exist in the same layer network;

Without an explicit boundary such as via the creation of two domains, 
mixing static and dynamic LSPs is a receipt for loops.

> 2. MPLS-TP Control Plane must provide a mechanism for MPLS-TP LSP dynamic ownership transfer from Management Plane to Control Plane and from Control Plane to Management Plane with 0 reconfiguration…

Same concern here.
> The second requirement means that it must be possible for the operator to statically provision an LSP and then have Control Plane to adopt the LSP (that is, create CP state for the LSP that already…
What is the application for this? This seems like a pretty major 
reprovisioning of the network is taking place.

Stewart

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 30 Mar 2009 10:51:43 -0400

Hi Stewart,

Please, see in-line.

Igor

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Monday, March 30, 2009 10:24 AM
To: Igor Bryskin
Cc: Ben Niven-Jenkins; [email-masked]
Subject: Re: [mpls-tp] Two additional MPLS TP requirements

IB>> Why?

Same concern here.

IB>> It could be many applications. One is transition: Control Plane is deployed, and all existing LSPs to be gradually moved under CP control. Also, operator may use Control Plane as an "automater" of certain but not all provisioning operations, but once the LSPs are in place, he might want LSPs to "forget" about their CP state (e.g. too many RSVP sessions).
Your point seems to be that in a given domain it is either MP or CP with the consequence that in some domains CP can fully replace MP. This is not what our clients (transport operators) would agree upon. They usually say that MP is always the "king".

Igor

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 30 Mar 2009 11:22:28 -0400

I agree with Igor on the first requirement - after all, ATM could do
this ... loops aren't a problem because a single LSP will either be
statically provisioned (like an ATM PVC), or dynamically signaled
(like an ATM SPVC or SVC). Having both types of LSPs in the same
domain works just fine.

The second requirement adds a lot of complexity to the equipment for
the bit of gain it gets you when you transition a particular LSP from
static provisioning to dynamic signaling.

Cheers,
Andy

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 30 Mar 2009 11:39:30 -0400

Andy,

As you probably know we have already a work in progress in the CCAMP WG on the dynamic ownership transfer. 

We (in ADVA) have an implementation in field for quite a while already. I can assure you that it does not add complexity to the equipment. It is a pure (and relatively simple) CP software feature which requires a little bit of cooperation from either DP or MP. Our clients love it and use far beyond the transition strategies.

Igor 

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]] 
Sent: Monday, March 30, 2009 11:22 AM
To: Igor Bryskin
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Two additional MPLS TP requirements

Cheers,
Andy

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 30 Mar 2009 10:39:10 -0700

+1 

> Sent: Monday, March 30, 2009 8:22 AM
> To: Igor Bryskin
> Cc: [email-masked]
> I agree with Igor on the first requirement - after all, ATM 
> could do this ... loops aren't a problem because a single LSP 
> will either be statically provisioned (like an ATM PVC), or 
> dynamically signaled (like an ATM SPVC or SVC). Having both 
> types of LSPs in the same domain works just fine.
> 
> The second requirement adds a lot of complexity to the 
> equipment for the bit of gain it gets you when you transition 
> a particular LSP from static provisioning to dynamic signaling.
> 
> Cheers,
> Andy
> 
> >> 1. It must be possible for statically and dynamically 
> >> provisioned/managed MPLS-TP LSPs to co-exist in the same layer 
> >> network;
> >>
> >
> >> 2. MPLS-TP Control Plane must provide a mechanism for 
> MPLS-TP LSP dynamic ownership transfer from Management Plane 
> to Control Plane and from Control Plane to Management Plane 
> with 0 reconfigurations in the Data Plane.
> >>
> >
> > Same concern here.
> >> The first requirement means, of course, that it must be 
> possible for an MPLS-TP layer network operator to setup and 
> manage some LSPs via Management Plane and some via Control Plane.
> >>
> >> The second requirement means that it must be possible for 
> the operator to statically provision an LSP and then have 
> Control Plane to adopt the LSP (that is, create CP state for 
> the LSP that already exists in the DP), so that form then on 
> the LSP could managed (e.g. re-routed, modified, released, 
> etc.) via Control Plane. Likewise, it must be possible for 
> the operator to use Control Plane to dynamically setup an 
> LSP, and once it is established have Control Plane to abandon 
> the LSP, so that from then on it would be indistinguishable 
> from the one that was statically setup.
> >>
> > IB>> It could be many applications. One is transition: 
> Control Plane is deployed, and all existing LSPs to be 
> gradually moved under CP control. Also, operator may use 
> Control Plane as an "automater" of certain but not all 
> provisioning operations, but once the LSPs are in place, he 
> might want LSPs to "forget" about their CP state (e.g. too 
> many RSVP sessions).
> > Your point seems to be that in a given domain it is either 
> MP or CP with the consequence that in some domains CP can 
> fully replace MP. This is not what our clients (transport 
> operators) would agree upon. They usually say that MP is 
> always the "king".
> >
> > Igor
> >
> >
> >
> >
> >

---

From: <[email-masked]>
Date: Mon, 30 Mar 2009 19:38:48 +0100

+2....wrt to the 1st point at least:  Igor's remarks, and Andy's, make
sense to me. But it does beg the question of why one would need a TTL
field in a co-ps mode layer network like MPLS-TP is supposed to
be.....because it for sure can't be for loop avoidance/mitigation as
Andy effectively observes.

And a more general observation...the closer to the duct the less dynamic
the network (and vice versa).  So for (long-holding) transport network
connections a MP solution is usally more appropriate than a CP
one....though I do hasten to add one should decouple the 2 aspects of
(i) route calculation and (ii) signalling.

regards, neil 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: 30 March 2009 18:39
> To: Andrew G. Malis; Igor Bryskin
> Cc: [email-masked]

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 30 Mar 2009 15:05:47 -0400

+3

On 1st point, this is a G8080 ASON requirement that both control plane
and management plane can be active:
"From the control plane view, control plane components operate directly
on the transport resources,
so control plane operation appears autonomous to the management plane.
Likewise, management
plane operations appear autonomous to the control plane. This is exactly
the same situation we have
when multiple managers manage equipment. Each manager is unaware of each
other's existence,
and simply sees autonomous equipment behaviour."

On the 2nd point, CCAMP has already completed the requirements and is
currently working on the solution:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-0
2.txt

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, March 30, 2009 2:39 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Two additional MPLS TP requirements

regards, neil

---

From: <[email-masked]>
Date: Mon, 30 Mar 2009 21:46:12 +0100

Thanks Huub.
who wrote 30 March 2009 14:44

> You are changing the subject.

NH=> Well, I am reacting to draft-bhh-mpls-tp-oam-y1731-01.txt and what
I see therein....so please forgive my desire to unpick what this
contains.

> how and where these tools are deployed is outside the scope.

NH=> Ah, the famous 'toolset'.  So we can wax lyrical on all manner of
things as long as its part of the mythical toolset....I see.  What
happens when the toolset is not appropriate for the job in-hand I
wonder?

> necessarily a 100% alignment with the PDUs defined in Y.1731,

NH-> Hmm....why do I smell snake oil?  Anyway back to the sound
engineering here.
-	No peer partition i/w of non top-of-stack layers
networks.......I'll take this as agreed as I've done it to death anyway
now;
-	No problem with CV and BDI functions....heck I was trying to get
folks on board with these basic OAM functions way back when I wrote
Y.1711 but some folks would not listen then;
-	Massive problem with TCM....this is far from 'obvious/necessary'
(in any layer network, not just MPLS-TP).

Ergo why I separated these 3 issues....they for sure should not come as
one amorphous lump....which does make me wonder exactly *what* those
operators whose signed up to this draft (assuming they had actually read
it) thought there were signing up to.  If the operators who signed up to
this draft disagree with me then I urge them to please get in contact
with me and I'll be very happy to discuss the technical details of what
is good/bad OAM with them.
> reason to discuss that in this subject.

NH=> Sounds good to me.....so I take this as that TCM (like peer
partition I/W) is now off the MPLS-TP agenda.  If so then thanks.  If
true this is indeed progress.  regards, Neil

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 30 Mar 2009 16:53:35 -0400

Deborah,

Thanks for the update on the draft for the second requirement - it had
escaped my attention (I completely missed ccamp this past week due to
conflicts).

Cheers,
Andy

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 30 Mar 2009 23:38:27 +0200

Hi Neil,

> Thanks Huub.

[hvh] You're welcome.

> I see therein....so please forgive my desire to unpick what this

[hvh] You picked on one abbreviation *TCME* and on
one section (5) header which will be removed in the next
revision...

> happens when the toolset is not appropriate for the job in-hand I

[hvh] What is mythical about Y.1731?

> NH-> Hmm....why do I smell snake oil?

[hvh] Maybe you openened the wrong bottle.

> Anyway back to the sound engineering here.

[hvh] As MPLS-TP is unaware of the content of the client packets,
it could be sound, but also video or data.

> (in any layer network, not just MPLS-TP).

[hvh] you are repeating yourself

> it) thought there were signing up to.

[hvh] if I were one of them I would take this as an insult.

> If the operators who signed up to
> true this is indeed progress. 

[hvh] ha ha, if you think that removing an abbreviation and a
section resolves *everything* you must have sipped from the bottle
with snake oil.

Cheers, Huub.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 31 Mar 2009 11:34:12 +0100

Igor,

Wrt requirement 1 I have added the following in the general requirements
section

MPLS-TP MUST support the co-existence of statically and dynamically
provisioned/managed MPLS-TP transport paths within the same layer network or
domain.

Wrt requirement 2 I have added the following in the control plane
requirements section

An MPLS-TP control plane MUST provide a mechanism for dynamic ownership
transfer of the control of MPLS-TP transport paths from the management plane
to the control plane and vice versa. The number of reconfigurations required
in the data plane MUST be minimised (preferably no data plane
reconfiguration will be required).

I'm now not going to accept any new requirements otherwise we'll never get
the document published.

Ben

On 30/03/2009 15:03, "Igor Bryskin" <[email-masked]> wrote:

> 1. It must be possible for statically and dynamically provisioned/managed
> MPLS-TP LSPs to co-exist in the same layer network;
> 
> 2. MPLS-TP Control Plane must provide a mechanism for MPLS-TP LSP dynamic
> ownership transfer from Management Plane to Control Plane and from Control
> Plane to Management Plane with 0 reconfigurations in the Data Plane.
> 
> The first requirement means, of course, that it must be possible for an
> MPLS-TP layer network operator to setup and manage some LSPs via Management
> Plane and some via Control Plane.
> 
> The second requirement means that it must be possible for the operator to
> statically provision an LSP and then have Control Plane to adopt the LSP (that
> is, create CP state for the LSP that already exists in the DP), so that form
> then on the LSP could managed (e.g. re-routed, modified, released, etc.) via
> Control Plane. Likewise, it must be possible for the operator to use Control
> Plane to dynamically setup an LSP, and once it is established have Control
> Plane to abandon the LSP, so that from then on it would be indistinguishable

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 31 Mar 2009 09:53:36 -0400

Ben,
Looks good to me. Just one comment: I think the requirement on the ownership transfer should be tighter: it must cause exactly 0 changes in the data plane to avoid any traffic hits.

Igor 

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Tuesday, March 31, 2009 6:34 AM
To: Igor Bryskin; [email-masked]
Subject: Re: Two additional MPLS TP requirements

Igor,

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 31 Mar 2009 15:11:44 +0100

Why?

My thinking is simple.

Ideally we want to say 0 reconfiguration, however the scenarios of moving
between CP & MP (or vice versa) is likely a migration step (I can't see SP's
flipping between the two very often) and therefore some impact may be
tolerated (e.g. If performed during a maintenance window)

Therefore I do not see 0 reconfiguration as an absolute must 0 i.e. If it
can't be done with 0 configurations then we declare solution is no good and
the requirement can't be met.

Ben

On 31/03/2009 14:53, "Igor Bryskin" <[email-masked]> wrote:

> Ben,
> Looks good to me. Just one comment: I think the requirement on the ownership
> transfer should be tighter: it must cause exactly 0 changes in the data plane
> to avoid any traffic hits.
> 
> Igor 
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 31 Mar 2009 16:28:03 +0200

Hi hopefully the requirement id we've done some time ago covers this requirement.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-06.txt

BR

Diego

__________________________________________
Diego Caviglia
Strategic Product Manager
Broadband Networks, PL Broadband Optical Network 
Ericsson Telecomunicazioni S.p.A. (TEI)
Via A. Negrone 1/A                           Office:  +39 010 600 3736
16153, Genova, Italy                          Fax: +39 010 600 3577
Block E Level 4                                  Mobile: +39 335 7181762
www.ericsson.com                       [email-masked]
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
________________________________

> Of Igor Bryskin
> Sent: martedì 31 marzo 2009 15.54
> To: Ben Niven-Jenkins; [email-masked]
> Looks good to me. Just one comment: I think the requirement on the
> ownership transfer should be tighter: it must cause exactly 0 changes in
> the data plane to avoid any traffic hits.
> 
> Igor
> 
> provisioned/managed

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 31 Mar 2009 23:12:06 +0100

Hi,

Since there is already a solution in the pipeline within CCAMP that achieves 
Igor's objective, I suspect the discussion is moot.

A
----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 31, 2009 3:11 PM
Subject: Re: [mpls-tp] Two additional MPLS TP requirements

>> ownership