Subject: [Mpls-interop] FW: I-D Action:draft-gray-mpls-tp-nm-req-01.txt

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 9 Oct 2008 21:10:35 +0200

Hi,
Thanks for the document.
I was surprised that expect for the following statement "Generic
configuration management requirements for transport network are
specified in G.7710 [1], for examples hardware, software, protection
switching, alarm reporting control, and date/time", I could not find any
requirement on the    provisioning and management of LSPs, PWs, on the
configuration of protection entities and functions, etc.
When we read an IEFT requirement draft I expect it addresses the entire
requirements and do not send us to read an ITU-T document in order to
gather the requirements.
LSPs' provisioning and management (like path resizing, change of the
constraints, release, etc.) are basic requirements of MPLS-TP. Also the
capability to decouple the protection switching from the Control Plane.
Today there is no standard way to configure the protection elements and
functions in all related LSRs. For example, the request to apply a
specific mechanism of FRR is signaled to all related LSRs while the LSP
is provisioned. There are no MIBs to configure it across the LSRs. We
need to configure it.
Best regards,
Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext
[email-masked]
Sent: Wednesday, October 08, 2008 18:00
To: [email-masked]
Subject: I-D Action:draft-gray-mpls-tp-nm-req-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : MPLS TP Network Management Requirements
	Author(s)       : S. Mansfield, et al.
	Filename        : draft-gray-mpls-tp-nm-req-01.txt
	Pages           : 19
	Date            : 2008-10-08

This document specifies the network management requirements for 

  supporting the Transport Profile for Multi-Protocol Label 

  Switching (MPLS-TP). 

  Gray, et al

  Expires April, 2009

[page 1] 

  Internet-Draft

MPLS-TP NM Requirements

  October, 2008

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gray-mpls-tp-nm-req-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 9 Oct 2008 16:37:21 -0500

Nurit,

	Thanks for the comment.

	This version does not represent a significant change from
the earlier version.  In it we address the few comments we have
received based on the -00 version.  Even though there were only
a few comments, they came from a number of people, so it is not
as if nobody has seen this draft before.

	It is our belief that it is completely appropriate to use
references as references, rather than copy them bodily into the
draft.  Of course, we will defer to Loa's and Stewart's opinion
on this - as well as the input from a larger number of others -
but we should be able to refer to any documents that are valid, 
available and reasonably authoritative.

	Moreover, the requirements referred to are generic and it
is not our intention to re-write them.  They apply in a context
that is much larger than the MPLS-TP environ and they have been
around some time.  In fact, it is very consistent with what we
have listed as requirements, that the generic requirements are
expected to be applied consistently with the way they have been
defined previously, in the generic transport context.

	Copying requirements into this draft might seem to imply
that we have change authority for these generic requirements, 
and open the floor to modifying them on a line-by-line basis.
This is not the case, and is - in addition - inconsistent with 
the intentions of this draft.

	If you have specific additional requirements that you can
demonstrate are indeed needed in this draft, please do so.  The
general observation that we should have copied all applicable
requirements from ITU documents into this draft is something we
do not currently plan to address.  For reasons given above, we
feel that this is both unnecessary and a bad idea.

--
Eric Gray
Principal Engineer
Ericsson  

> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
> [mailto:[email-masked]] 
> Sent: Thursday, October 09, 2008 3:11 PM
> To: Scott Mansfield; [email-masked]; Eric Gray
> Cc: MEAD team
> Subject: FW: I-D Action:draft-gray-mpls-tp-nm-req-01.txt 
> Importance: High
> 
> 
> Hi,
> Thanks for the document.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 10 Oct 2008 02:05:35 +0200

Hi Eric,
Thanks for the clarifications.
Please see inline.
Best regards,
Nurit

-----Original Message-----
From: ext Eric Gray [mailto:[email-masked]] 
Sent: Thursday, October 09, 2008 23:37
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team; Scott Mansfield; [email-masked]
Subject: RE: I-D Action:draft-gray-mpls-tp-nm-req-01.txt 

Nurit,

	Thanks for the comment.

	It is our belief that it is completely appropriate to use
references as references, rather than copy them bodily into the
draft.  
<Nurit> I think it is OK (and even recommended) to refer to other IETF
documents instead of copying text (which may cause to inconsistency in
the future), but IMO this is not the case with requirements that are
specified in ITU-T documents. 

Of course, we will defer to Loa's and Stewart's opinion
on this - as well as the input from a larger number of others -
but we should be able to refer to any documents that are valid, 
available and reasonably authoritative.

	If you have specific additional requirements that you can
demonstrate are indeed needed in this draft, please do so.  
<Nurit> I think I already gave some examples in the mail below.
The
general observation that we should have copied all applicable
requirements from ITU documents into this draft is something we
do not currently plan to address.  For reasons given above, we
feel that this is both unnecessary and a bad idea.

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Thu, 9 Oct 2008 21:07:11 -0500

Hi Nurit,

Please note that the requirement we are talking about here is the
generic transport management requirement. In my opinion, referring to
ITU-T documents (G.7710 in this case) is very appropriate.

Regards,
Kam 

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: Thursday, October 09, 2008 8:06 PM
To: ext Eric Gray
Cc: MEAD team; Scott Mansfield; Lam, Hing-Kam (Kam)
Subject: RE: I-D Action:draft-gray-mpls-tp-nm-req-01.txt 

Hi Eric,

-----Original Message-----
From: ext Eric Gray [mailto:[email-masked]] 
Sent: Thursday, October 09, 2008 23:37
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team; Scott Mansfield; [email-masked]
Subject: RE: I-D Action:draft-gray-mpls-tp-nm-req-01.txt 

Nurit,

	Thanks for the comment.

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 10 Oct 2008 08:28:47 +0200

Hi,
I thought the document specifies the MPLS-TP NM requirements and not the
generic transport requirements.
ITU-T and IETF documents speak in different "languages". What is it a
"trail' in an IETF language, is it an end-to-end transport path that is
being monitored? What is "subnetwork connection", is it a segment of the
trail that is being monitored? Do you think that every IETF reader is
aware of this terminology? 
I am also pretty sure that some of the readers will have difficulty to
understand figure 4 which provides an example of management network
relationships. 
OSS based provisioning and management of LSPS is a fundamental
requirement of MPLS-TP. Why should not we even mention it in the
document?
Also, a significant extension (but not only) to the survivability
mechanisms in MPLS-TP is the capability to enable the protection
switching even in the absence of a control plane. Why should we find a
requirement to configure the protection entities and functions?
The setup of a Tandem Connection is also a significant requirement of
MPLS-TP (in order to manage and monitor the network in different nested
levels). Why should not we include such a requirement in our specific
case document?  
Etc.
Best regards,
Nurit

-----Original Message-----
From: ext Lam, Hing-Kam (Kam) [mailto:[email-masked]] 
Sent: Friday, October 10, 2008 04:07
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Eric Gray
Cc: MEAD team; Scott Mansfield
Subject: RE: I-D Action:draft-gray-mpls-tp-nm-req-01.txt 

Hi Nurit,

Regards,
Kam 

-----Original Message-----

Hi Eric,

-----Original Message-----
From: ext Eric Gray [mailto:[email-masked]] 
Sent: Thursday, October 09, 2008 23:37
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team; Scott Mansfield; [email-masked]
Subject: RE: I-D Action:draft-gray-mpls-tp-nm-req-01.txt 

Nurit,

	Thanks for the comment.

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 10 Oct 2008 05:13:46 -0500

Nurit,

	It may be necessary for us (the MEAD group as a whole) to 
provide a document that defines a terminology mapping.  Maybe
this document would be the place to do that, but I don't know
(and I don't think so).  A more likely candidate for this sort 
of terminology mapping might be in the MPLS-TP Framework draft, 
since this is a problem that applies generally to the problem 
space and not just to network management.

	The terms you ask about below ("subnetwork connection",
"trail") are examples of this.  These may need to be defined
more generally than in a NM requirements document.

	As far as the figure you mention is concerned, there is
an opportunity there for more work in explaining the diagram
in a way that is more likely to be understood in this context.
We welcome your help in this effort.

	As for the remainder of your suggestions, writing this 
draft - as in writing any other - is an iterative process.  As
other drafts include more detail that impacts on requirements
of network management, we may need to add more detail as well.
We cannot anticipate supposed detail of work in other drafts.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Friday, October 10, 2008 2:29 AM
> To: ext Lam, Hing-Kam (Kam); Eric Gray

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 10 Oct 2008 12:40:27 +0200

Hi Eric,
Thanks for your response.
I definitely agree that writing a draft is an iterative process. 
My intention was not to criticize the draft but to provide constructive
comments. I did not expect this document to map the ITU-T terminology
into IETF ones. But I thought that we can not eliminate requirements
that are specified in the ITU-T document and refer the readers to gather
the requirements from the ITU-T document, as they need to understand the
ITU-T environment and terminology.
By the way, as a naive question, do you think that all the requirements
that appear in the ITU-T document apply to MPLS-TP?  
In any case, I'll be glad to support and help.
Best regards,
Nurit

-----Original Message-----
From: ext Eric Gray [mailto:[email-masked]] 
Sent: Friday, October 10, 2008 12:14
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team; Scott Mansfield; ext Lam, Hing-Kam (Kam)
Subject: RE: I-D Action:draft-gray-mpls-tp-nm-req-01.txt 

Nurit,

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 10 Oct 2008 05:54:28 -0500

Nurit,

	The question about applicability of the requirements is
not naive; it is actually quite profound.  This is a question
that probably requires a lot of thinking and discussion at a
level of detail probably greater than I suspect is intended 
for this draft.

	At a somewhat higher level, however, I strongly suspect
the ITU requirements were written to apply generally - with an
implicit understanding that not all requirements apply in each
specific instance.  Does that mean that a separate document is
required in each specific case to list the subset that applies
in that case?  That could be a good question...

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Friday, October 10, 2008 6:40 AM
> To: Eric Gray

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 10 Oct 2008 14:01:24 +0100

RFC 4397 may help with some of the terminology mapping (but probably not
all).

I tend to agree with Eric, I don't think we should be effectively copy &
pasting whole chunks of ITU text into IETF drafts especially as ITU Recs are
now publicly available for free.

We may need some additional text to aid the reader to understand ITU
terminology, diagrams etc.

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 10 Oct 2008 16:09:20 +0200

Hi Ben,

I would tend to agree if we specified the requirements and refer to
rational in the ITU-T documents (as we did in certain cases with the
MPLS-TP requirements draft) . But........

1.    Even with terminology mapping it may not be so easy to understand
the ITU-T figures and text. 

2.    If we refer to the ITU-T document for the requirements, we need to
review also the ITU-T document and see whether we think that all the
requirements there are relevant for MPLS-TP (and if not we should
clearly indicate in our document which are not relevant or vise versa
which are relevant). In addition we need to see if something is missing
(for example there is nothing regarding the configuration of FRR, etc.).

3.    I think that since one of the fundamental requirements in MPLS-TP
is to have also an OSS based provisioning and management, we need to
address it in the IETF. Otherwise we could just refer to the document
and not include anything also on fault management and performance
monitoring. 

Loa, what is your view on this?

Best regards,

Nurit

-----Original Message-----
From: ext Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Friday, October 10, 2008 15:01
To: Eric Gray; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: Re: [Mpls-interop] I-D Action:draft-gray-mpls-tp-nm-req-01.txt

all).

pasting whole chunks of ITU text into IETF drafts especially as ITU Recs
are

Ben

>> I thought the document specifies the MPLS-TP NM requirements

>> and not the

>> "trail' in an IETF language, is it an end-to-end transport

>> path that is

>> being monitored? What is "subnetwork connection", is it a

>> segment of the

>> MPLS-TP (in order to manage and monitor the network in

>> different nested

>>> switching, alarm reporting control, and date/time", I could

>>> not find any

>>> requirement on the    provisioning and management of LSPs,

>> PWs, on the

>>> When we read an IEFT requirement draft I expect it addresses

>>> the entire

>>> requirements and do not send us to read an ITU-T document

>> in order to

>>> constraints, release, etc.) are basic requirements of

>>> MPLS-TP. Also the

>>> capability to decouple the protection switching from the

>>> Control Plane.

>>> Today there is no standard way to configure the protection

>>> elements and

>>> specific mechanism of FRR is signaled to all related LSRs

>>> while the LSP

>>> is provisioned. There are no MIBs to configure it across

>> the LSRs. We

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Fri, 10 Oct 2008 10:12:21 -0500

Hi Nurit,

Your comment #2 is fair enough. Any specific are welcome. You already
raised some. We will work on that.

On your comment #3: Please note that the subject I-D is on NM
requirement. Whether these requirements could be met by mechanism such
as OSS based or Craft base that should be covered in other document. May
be the yet to be created NM Framework is the right document for that
purpose. Your last statement says "Otherwise we could just refer to the
document and ....". I don't know you mean G.7710 or the nm-req I-D. But
both documents do address fault management and performance monitoring
and more, such as configuration management (which include provisioning)
and security management. Again, if any specific requirements are
missing, please raise.

Regards,

Kam 

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
- IL/Hod HaSharon)
Sent: Friday, October 10, 2008 10:09 AM
To: ext Ben Niven-Jenkins; Eric Gray
Cc: MEAD team
Subject: Re: [Mpls-interop] I-D Action:draft-gray-mpls-tp-nm-req-01.txt

Hi Ben,

Best regards,

Nurit

-----Original Message-----
From: ext Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Friday, October 10, 2008 15:01
To: Eric Gray; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: Re: [Mpls-interop] I-D Action:draft-gray-mpls-tp-nm-req-01.txt

all).

Ben

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 10 Oct 2008 11:47:39 -0400

Can understand given the time requirements, it's still a work in
progress;-)

Though I think we should be a bit careful so as not to confuse or
portray that "all" transport requirements apply for MPLS-TP. Some
filtering should be used and then can always add later to the document
if identify others.

For example, I got confused on:
"Performance degradation MUST be reported via performance monitoring,
e.g. as Errored Second (ES), Severely Errored Second (SES), and
Unavailable Second (UAS), for Service Level Agreement (SLA) verification
and billing."

First, I was not sure if ES, SES, UAS has been determined as required
for MPLS-TP. And second, do you have a reference that these parameters
are used for MPLS-related SLAs?

Deborah

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Friday, October 10, 2008 9:01 AM
To: Eric Gray; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: Re: [Mpls-interop] I-D Action:draft-gray-mpls-tp-nm-req-01.txt

Ben

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 10 Oct 2008 11:24:36 -0500

Deborah,

	A reference showing these parameters being used for MPLS
based SLAs is a little difficult to come up with at this point,
given that we are working on defining an MPLS profile suitable 
for use in transport networks.  Do you know of anyone currently
using MPLS for transport in the sense of MPLS-TP?

	The working assumption - as I understand it - is that the
performance monitoring requirements defined generically for all
transport technologies are expected to apply to MPLS when used
in this fashion as well.  The reason for this is to allow for
"apples-to-apples" performance comparisons.  In the draft, the 
text following the text you specifically cited explains how 
these measurements are expected to be made.  

	Is there a problem with the way that these are defined?
Is the working assumption something other than as I describe?
Are your expectations (as an operator) that "apples-to-apples"
comparison of performance is not important for you?

--
Eric Gray
Principal Engineer
Ericsson  

> From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
> Sent: Friday, October 10, 2008 11:48 AM
> To: Eric Gray
> Cc: MEAD team
> Subject: RE: [Mpls-interop] I-D 
> Action:draft-gray-mpls-tp-nm-req-01.txt
> Importance: High
> 
> >> switching even in the absence of a control plane. Why 
> should we find
> a

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 10 Oct 2008 13:28:01 -0400

Hi Eric,

To give a quick answer, apples-to-apples comparisons is only useful if
both are apples (i.e. it's meaningful). But that's a topic which should
be discussed by SG15 and SG12 (and IETF performance wgs).

It would be more helpful, if there is no reference, and if this is the
justification for including in this document, that it should be simply
stated as this (and have a note to say it's understudy). And not say
it's for SLA purposes. I would say, as an operator, if MPLS-TP is used
in the network (or one domain), it should be transparent to the customer
i.e. SLAs as done today for MPLS would be applicable (this is of benefit
to both operator and customer). Of course, every operator is on their
own for defining their SLAs. But I think it is misleading for this
document to justify these transport parameters as "MUST" for SLA use
unless there is a reference.

Thanks,
Deborah

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Friday, October 10, 2008 12:25 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: MEAD team
Subject: RE: [Mpls-interop] I-D Action:draft-gray-mpls-tp-nm-req-01.txt

Deborah,

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 10 Oct 2008 12:40:24 -0500

Deborah,

	I guess we'll have to look into it, so it is under study 
at this point.

	However, one of the things you mention doesn't make sense
to me.  The apples-to-apples comparison is between a service 
transported using MPLS-TP and another service transported using
TDM - not between a service transported using MPLS-TP and another 
service transported using MPLS.

	Or at least that's my understanding.  Is your understanding 
different?  If we're expecting operators to replace MPLS services
with MPLS-TP services (as opposed to replacing other transports
with MPLS-TP) what's the point?

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Friday, October 10, 2008 1:28 PM
> To: Eric Gray
> Cc: MEAD team
> > >> I am also pretty sure that some of the readers will have 
> difficulty
> > to
> > >> documents instead of copying text (which may cause to 
> inconsistency
> > in

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 10 Oct 2008 14:24:06 -0400

Exactly..

If one is providing an Ethernet service (i.e. Ethernet SLAs), the use of
MPLS or MPLS-TP or both, doesn't require MPLS-TP to support ES, SES,
UAS. Today, an operator could support the Ethernet service with MPLS or
GFP/SONET. But these different options don't impact how we measure the
performance of MPLS or GFP/SONET or doing SLAs.

If an operator using MPLS-TP is "more comfortable" with ES/SES/UAS
measurements than that's the justification, but it doesn't have anything
to do with "MUST..for SLAs". I'm just saying let's be careful how we
justify these requirements so as not to confuse.

Deborah 

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Friday, October 10, 2008 1:40 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: MEAD team
Subject: RE: [Mpls-interop] I-D Action:draft-gray-mpls-tp-nm-req-01.txt

Deborah,

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 10 Oct 2008 13:43:28 -0500

Deborah,

	I see.  In the case where MPLS-TP is being used for 
Ethernet, this level of SLA measurement is probably not 
required.  If - as we had thought at the time - MPLS-TP
is meant to support circuit emulation (for example) and 
only incidentally one of the applications for this might
be Ethernet transport, then a different comparison is
needed.

	I don't necessarily agree that this is a matter of
an operator being "more comfortable" with the particular
metrics, as much as it is a matter of how operators plan
to use the transport service.  

	In any case, we will hopefully be able to discuss
this next week...

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Friday, October 10, 2008 2:24 PM
> To: Eric Gray
> Cc: MEAD team
> > > >> <Nurit> I think it is OK (and even recommended) to 
> refer to other
> > > IETF