Subject: [Mpls-interop] Meeting notes from the MEAD meeting 10/15-17/2008

From: David Sinicrope <[email-masked]>
Date: Sun, 19 Oct 2008 14:24:44 -0700

Hi All,
At the link below are the meeting notes for the meeting last week.  Included in the .zip file are the two slide presentations from Dave Ward and Italo Busi on Loopback and PHP respectively.
Please let me know if you have any questions, comments or missed anything.
http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/meeting-notes/20081015.mpls-interop-dt-notes.zip
Dave Sinicrope
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 20 Oct 2008 07:57:47 +0200

HI,

Thanks for the minutes.

A few comments from my side on the first page that I managed to read:

(1) In general, meetings on Fridays are problematic for us in IL. 

(2) I was surprised to read that " The introduction is text that was
taken from ITU-T on why we are creating these requirements". As the
writer (also) of most of the introduction, I can tell you that it is not
taken from the ITU-T. It was integrated with the text that Ben
originally put from the ITU-T. I think it is important to include the
motivation in the introduction section and this is something that is
common in many of the requirement drafts. If something is missing we
should include it as well.

I'll go over the rest of the minutes and see if I have further comments.

Best regards,

Nurit

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext David Sinicrope
Sent: Sunday, October 19, 2008 23:25
To: [email-masked]
Subject: [Mpls-interop] Meeting notes from the MEAD meeting
10/15-17/2008

Hi All,
At the link below are the meeting notes for the meeting last week.
Included in the .zip file are the two slide presentations from Dave Ward
and Italo Busi on Loopback and PHP respectively.
Please let me know if you have any questions, comments or missed
anything.
http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/meeting-not
es/20081015.mpls-interop-dt-notes.zip
Dave Sinicrope

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Oct 2008 15:30:28 +0100

Looks like you had some discussion of the term "domain" in Boston.

Did anyone look at RFC 4726?

A

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Oct 2008 15:36:07 +0100

In Boston you seem to have got into a lather about addresses and 
identifiers.

Is the problem any different from that in any other IETF transport network? 
For example a GMPLS-controlled optical network? I think that such networks 
do not forward IP in the data plane.

If you think the problem space is similar, perhaps it may help to look at 
RFC 4990.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Oct 2008 16:53:04 +0100

Just to reiterate something discussed by email while you were in Boston.

The minutes state
.  In GMPLS, MIBs cover monitoring, but not provisioning.

This is not true.
The GMPLS MIBs and the original MPLS MIBs on which they are built *do* 
support PVCs.
You can use the MIB modules to manually provision LSPs, i.e. to build PVCs. 
In other words, the IETF has supported MPLS PVCs for over four years, and 
has been working on the topic for over seven years.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Oct 2008 17:04:59 +0100

Hi,

In Boston you noted...

There was some general sentiment that the document is too ITU-T specific 
with too much ITU-T terminology.  We agreed to address this via a rosetta 
stone mapping of terminology as well as some explanation mapping the IETF to 
the ITU-T terms and architecture.

Can I point you at RFC 4397. I think this will give you are large percentage 
of what you need with the benfit that it has already had extensive review by 
the ITU-T transport architects.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Oct 2008 17:11:21 +0100

It looks from the minutes as though you discussed counting "lost packets."

That would be pretty clever, IMHO.

I think you can only count "errored packets received" and "packets dropped 
on receipt." You can certainly break those counts down by reason code.

Basic performance and error counters were included in RFC 3812.

Adrian

---

From: <[email-masked]>
Date: Mon, 20 Oct 2008 18:12:40 +0200

Hi Adrian.

In the last page of the minutes, you'll see that RFC 4397 has been
mentioned. :-)

Julien

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adrian Farrel

Hi,

In Boston you noted...

with too much ITU-T terminology.  We agreed to address this via a
rosetta 
stone mapping of terminology as well as some explanation mapping the
IETF to 
the ITU-T terms and architecture.

Can I point you at RFC 4397. I think this will give you are large
percentage 
of what you need with the benfit that it has already had extensive
review by 
the ITU-T transport architects.

Thanks,
Adrian

---

From: <[email-masked]>
Date: Mon, 20 Oct 2008 18:17:30 +0200

Hi Adrian.

I have the feeling that the way the term "domain" has been used was
sometimes more generic than what is defined in RFC 4726. Anyway, it's
clearly unnecessary to redefine it from scratch.

Julien

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

A

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 20 Oct 2008 18:23:06 +0200

Hi Adrian,

You wrote:

> rosetta stone mapping of terminology as well as some explanation mapping 
> the IETF to the ITU-T terms and architecture.
> 
> percentage of what you need with the benfit that it has already had 
> extensive review by the ITU-T transport architects.

Don't worry. Both your name and the RFC4397 were mentioned.
As I volunteered to collect all terms that need a translation,
I will use the RFC as a reference.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 20 Oct 2008 18:27:19 +0200

Hi Adrian,

> That would be pretty clever, IMHO.

The glass ball used in this case could be an OAM PDU containing
a count of the packets sent since the previous OAM PDU with the
count was sent.

> I think you can only count "errored packets received" and "packets 
> dropped on receipt." You can certainly break those counts down by reason 
> code.

Indeed, and they will contribute to PM as well.

Thanks,

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 20 Oct 2008 18:30:25 +0200

Hi,

On Friday Stuart was still in hospital.

Is there anyone who knows if he was released and has returned
home in a better condition?

Regards, Huub.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Oct 2008 17:16:52 +0100

Obviously I should read from the bottom upwards :-)
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, October 20, 2008 5:12 PM
Subject: RE: [Mpls-interop] A Rosetta Stone for MPLS-TP transport 
terminology

Hi Adrian.

Julien

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

Hi,

In Boston you noted...

Thanks,
Adrian

---

From: <[email-masked]>
Date: Mon, 20 Oct 2008 18:56:10 +0200

I would say that the problem is different.

In our typical GMPLS contexts, we consider that controlled data planes
have their own OAM mechanisms. In optical networks, OAM mechanisms come
indeed intrinsically with circuit-based technologies.

In the MPLS-TP context, we are isolating the MPLS network layer,
therefore the data plane does not do IP forwading. However, MPLS used to
be tied with the IP network layer, thus sharing control (that can be
addressed separately thanks to GMPLS) and OAM (that is not defined yet
in an IP-less MPLS context). Dave's point was that OAM require that
head-end to be identified at tail-end and that IP addressing fits the
job (default in BFD).

Does it clarify the context and issues?

Cheers,

Julien

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

Is the problem any different from that in any other IETF transport
network? 
For example a GMPLS-controlled optical network? I think that such
networks 
do not forward IP in the data plane.

If you think the problem space is similar, perhaps it may help to look
at 
RFC 4990.

Adrian

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 20 Oct 2008 13:11:52 -0400

> has been working on the topic for over seven years.

    Correct, as you can with their underlying MPLS base MIBs.  Given this, I
see no need to develop something new in this area of standards for MPLS-TP.

    --Tom

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 20 Oct 2008 15:54:39 -0400

The comment came up wrt to section 1.2 and the (loose) use of "domain"
in the other sections:
"The encapsulated client signals are extracted at the edges of
aggregation domains, and are either delivered to the client or forwarded
to another domain."

This (loose) use of domain in the requirements was based on ITU's
generalized domain definition. G8081 says:
"A domain represents a collection of entities that are grouped for a
particular purpose. See ITU-T Rec. G.8080/Y.1304."
And G8080 says:
"The domain notion embodied in the G.805 definition of administrative
domain and the Internet administrative regions (e.g., Autonomous
Systems) has been generalized in the control plane architecture to
express differing administrative and/or managerial responsibilities,
trust relationships, addressing schemes, infrastructure capabilities,
survivability techniques, distributions of control functionality, etc.
Domains are established by operator policies and have a range of
membership criteria, as exemplified above."

We can sort out if the definition should be in the requirements or in
the terminology document - as it will be used across the documents
probably the terminology document is the best home.

Deborah

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, October 20, 2008 12:18 PM
To: [email-masked]; [email-masked]
Subject: Re: [Mpls-interop] Discussion of domain

Hi Adrian.

Julien

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

A

---

From: George Swallow <[email-masked]>
Date: Mon, 20 Oct 2008 16:09:55 -0400

Spoke to him last night.  Was still in hospital, but feeling much better and
hoping to be released today.

...George

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 20 Oct 2008 16:13:28 -0400

Hi Nurit,
 
The comment was in the context of this paragraph:

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
- IL/Hod HaSharon)
Sent: Monday, October 20, 2008 1:58 AM
To: ext David Sinicrope; [email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] Meeting notes from the MEAD meeting
10/15-17/2008

HI,

Thanks for the minutes.

Best regards,

Nurit

Hi All,

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 20 Oct 2008 16:21:38 -0400

Hi Nurit,
(hopefully I don't hit send before completing this time;-)
 
This sentence was in the context of the whole paragraph:
"We use SONET/SDH in the intro quite a bit. Should we also mention
Ethernet and the direction the technology is headed and should we
mention light paths?  We don't want to convey that we are trying to
redefine SONET.

This should work with packets in G.709.  The introduction is text that
was taken from ITU-T on why we are creating these requirements, but we
don't want to make presumptions on the technology paths that will be
followed."
 
The concern was why we re-used ITU's statements on SONET/SDH as the
benchmark for migrating to packet transport networks - suggesting we
should generalize so as to be more future-oriented on (other) transport
technologies.
 
Deborah

HI,

Thanks for the minutes.

Best regards,

Nurit

Hi All,

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 20 Oct 2008 16:35:11 -0400

Has SG15 discussed this mechanism with ITU's performance SGs? E.g. SG12?
Within IETF, it would be good to discuss with IP performance wgs.

As I noted on the other parameters (ES, etc), we are mixing requirements
with legacy concepts/solutions (ES, SES, UAS). First, we need an
understanding/requirements of what is meaningful for packet networks.

Deborah 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Monday, October 20, 2008 12:27 PM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [Mpls-interop] Counting lost packets

Hi Adrian,

Thanks,

Regards, Huub.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 20 Oct 2008 22:34:45 +0100

Using a combination of RFC4726, G8081 and G8080 I have come up with the
following definition for draft-jenkins

Domain: A domain represents a collection of entities (for example network
elements) that are grouped for a particular purpose, examples of which are
administrative and/or managerial responsibilities, trust relationships,
addressing schemes, infrastructure capabilities, survivability techniques,
distributions of control functionality, etc. Examples of such domains
include IGP areas and Autonomous Systems.

I welcome flames as to how far from the mark the above definition is.

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Oct 2008 22:39:19 +0100

Ben, that's beautiful.

:-)

A
----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Monday, October 20, 2008 10:34 PM
Subject: Re: [Mpls-interop] Discussion of domain

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 20 Oct 2008 22:44:50 +0100

I believe the second part of the paragraph is essentially quoting what I
said during the meeting where I did state that the intro was basically taken
from ITU-T documents (after much editing before issuing -00 of draft-jenkins
I can no longer remember the exact source of parts of the document).

Personally having re-read the introduction I do think it has a heavy focus
on SONET/SDH which I don't believe was our (or at least my) intention.

As I edit up draft-jenkins this week I will try and see what I can do with
the introduction but if anyone has any suggested text changes please send
them to me to make my life easier :-).

Ben

---

From: "Thomas Walsh" <[email-masked]>
Date: Mon, 20 Oct 2008 22:55:04 -0400

Later update.  He is doing quite well now and will be released from the
Hospital Tuesday.  He expects to fly home on Wednesday.

Tom

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of George Swallow
> Sent: Monday, October 20, 2008 4:10 PM
> To: [email-masked]
> Subject: Re: [Mpls-interop] Stuarts condition
> 
> Spoke to him last night.  Was still in hospital, but feeling much
better
> and

---

From: "LEVRAU, LIEVEN \(LIEVEN\)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:13:06 +0200

Sounds good, Ben.

./
Lieven
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: 20 October 2008 23:35
To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Mpls-interop] Discussion of domain

Domain: A domain represents a collection of entities (for example
network
elements) that are grouped for a particular purpose, examples of which
are
administrative and/or managerial responsibilities, trust relationships,
addressing schemes, infrastructure capabilities, survivability
techniques,
distributions of control functionality, etc. Examples of such domains
include IGP areas and Autonomous Systems.

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:38:07 +0200

Hi,

I went over half of the minutes and I have a few questions, as follows:

*	"MPLS-TP must not dictate the deployment of any particular
network topology either physical or logical".

	*	Will it be required from nodes to be aware of the
specific topology in specific cases (e.g. in protection)?

*	"Why do you need to identify the source?  To detect mis-merge
you need to have the label and source IP address.  To send something
back to source you need source IP address of node that generated OAM
packet.  Don't need full FEC just IP address and identifier of LSP."

	*	We need to identify uniquely the transport path. Are the
source IP address and label sufficient? Does it work also for the case
when we have more than one LSP between source and destination?
Identifier of LSP and label are not necessarily the same thing. Label
has local scope and identifier. LSP identifier may have local scope
between src and dst.
	*	I ma not sure I fully understand "for fwd OAM demux - IP
address". I'll appreciate a clarification. 

*	"Note: As new services are defined, new GAL or GACH can be
defined identifying new service contexts such as Ethernet OAM.  E.g., if
using Eth OAM then these defaults may not be used because of other
mechanisms."

	*	I do not understand how Ethernet OAM relates to GAL or
GACH. DO we expect to process Ethernet OAM within the MPLS-TP transport
network or just transmit them over a PW as any data traffic?

*	The intermediate nodes must be aware...An intermediate node is
not aware of bidirectional connectivity.  For GMPLS they were set up at
the same time with the same RESV then the knowledge is there.  It would
be torn down using the 5tuple mentioned previously.  For PW the
intermediate nodes will not know bidirectional at all.  Add the words
"at each layer". For MS PW there is a path TLV that allows for
bidirectional signaling of the PW so the nodes are probably aware.

	*	I think it is clear that we are considering GMPLS for
MPLS-TP, then we can expect this kind of information. This is important
for functions like AIS, etc. 
	*	For SS PW I think the terminating points are aware of
the relationship as if the service is Ethernet there is one
cross-connect between the PW and the Ethernet port. 

*	"The group agreed to not list out the specific FM and PM
functions we want.  They should be in the Net Mgmt documents."

	*	I do not agree to this statement. I expect a requirement
draft on OAM to include the specific functions that are required to
implement. 
	*	This cannot be included in the Net Mgmt document,
because I all functions should work independently if they are configured
and managed by NMS or CP or any other mechanism. 

*	"Are we going to use OAM for protection trigger?  Could use for
APS"

	*	The survivability document clearly specifies that one of
the triggers a protection switching may be OAM (e.g. loss of CC&CV,
etc.)
	*	APS is not a function but an ITU-T message. We propose
to call it PSC indicating that this is coordination between the states
of the peers. 

*	"Control plane must support pre-provisioned path... replace
provisioned with allocated. Control plane must support fast
restoration... define fast restoration.  Initial discussions indicate
50ms,"

	*	As specified in the survivability document, we can talk
about pre-calculated and about pre-provisioned. I would not change
provisioned by allocated.
	*	I never heard about a discussion on 50ms for restoration
but for protection. Or maybe you meant recovery? 

*	"Move restoration/protection requirements for the cplane to
cplane section in section 2.8 can cross reference."

	*	I am not sure why we should move a function that needed
to be supported by both MP and CP to a section on CP. I would like to
see the requirements on recovery in a single place. If required, refer
to this section from the section on the CP. 

*	I am not sure I am following the conclusion about the addressing
and identifiers. I'll appreciate a clarification,
*	I am not sure I am following the conclusion about domains. I'll
appreciate a clarification.

I still have to go over the rest of the minutes and come back if I have
comments/question.

Best regards,

Nurit

Hi All,

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:38:31 +0200

I second this.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Monday, October 20, 2008 16:36
To: [email-masked]
Subject: [Mpls-interop] Addressing and Identifiers

Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:41:06 +0200

Does they support the configuration of recovery functions and entities
as well?
By the way the MPLS MIBs also support static portioning of LSps and PWs.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Monday, October 20, 2008 17:53
To: [email-masked]
Subject: [Mpls-interop] MIBs and PVCs

The minutes state

This is not true.
The GMPLS MIBs and the original MPLS MIBs on which they are built *do* 
support PVCs.
You can use the MIB modules to manually provision LSPs, i.e. to build
PVCs. 
In other words, the IETF has supported MPLS PVCs for over four years,
and 
has been working on the topic for over seven years.

Thanks,
Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:46:52 +0200

I think the issue of backward compatibility and interworking should
really be discussed.
Still I think we can define a solution that can also work in IP-less
environment. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext
[email-masked]
Sent: Monday, October 20, 2008 18:56
To: [email-masked]; [email-masked]
Subject: Re: [Mpls-interop] Addressing and Identifiers

Cheers,

Julien

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

Adrian

---

From: "LEVRAU, LIEVEN \(LIEVEN\)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:47:39 +0200

Suggest to chop up your points in separate emails to avoid long treaded
and at the end of the day confusion emails 

Changed the subject line to - MPLS-TP  topology dependency 

I don't think so -However, if specifics on the underlying topo are
required for, say protection, suggest to to incorporate and detail it in
that specific document (the doc dealing with Ring protection) 

./

Lieven

Sent: 21 October 2008 19:38

Hi,

Best regards,

Nurit

Hi All,

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:50:36 +0200

Hi Deborah,

Thanks for the clarification. 

Still I think that the migration from SONET/SDH to packet transport
network is one of the big motivation and we should include it. 

Best regards,

Nurit

From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Monday, October 20, 2008 22:22
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext David Sinicrope;
[email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] Meeting notes from the MEAD meeting
10/15-17/2008

Hi Nurit,

Deborah

HI,

Thanks for the minutes.

Best regards,

Nurit

Hi All,

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:53:18 +0200

I think it is a good definition.
Maybe in the example we should talk more about roles - like a SP
network, subnetworks of a SP that are operated by different operators,
etc. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Ben
Niven-Jenkins
Sent: Monday, October 20, 2008 23:35
To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Mpls-interop] Discussion of domain

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:59:07 +0200

Even when we talked about 50ms protection switching in the meeting with
the SPs, I remember that one of the SPs said that since the packet
transport network and specifically MPLS-TP intends to replace SONET/SDH
we should provide the same capabilities that the customers were used to
get in the SONET/SDH networks, even if it is not really necessary.

We should refer to SONET/SDH to see if we can address the capabilities
in MPLS-TP.

This was also the motivation of the ITU-T and this is joint work between
ITU-T and IETF.  

From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
Sent: Tuesday, October 21, 2008 19:51
To: 'ext BRUNGARD, DEBORAH A, ATTLABS'; ext David Sinicrope;
[email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] Meeting notes from the MEAD meeting
10/15-17/2008

Hi Deborah,

Best regards,

Nurit

Hi Nurit,

Deborah

HI,

Thanks for the minutes.

Best regards,

Nurit

Hi All,

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 21 Oct 2008 14:13:35 -0400

On Oct 21, 2008, at 1:41 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon)  

> Does they support the configuration of recovery functions and entities

	In some cases, yes. It depends what you mean by 'recovery function'.
	
> By the way the MPLS MIBs also support static portioning of LSps and  

	Yes, they do.  I know of a few vendors that actually deployed them in  
this way.

	--Tom

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Tue, 21 Oct 2008 14:22:54 -0400

Regarding the 50 ms restoration requirement, it originated in SONET/SDH as the shortest length of time in which an outage would be audible to the human ear in a voice call. However, it has since been incorporated in both TDM and data SLAs to end customers, especially those with private line services. So it is a firm requirement, at least for this service provider, especially if we ever hope to retire our SONET/SDH infrastructure and replace it with packet-based services (including circuit emulation).
 
Cheers,
Andy

From: [email-masked] on behalf of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Tue 10/21/2008 1:59 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext BRUNGARD, DEBORAH A, ATTLABS; ext David Sinicrope; [email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] Meeting notes from the MEAD meeting 10/15-17/2008

Even when we talked about 50ms protection switching in the meeting with the SPs, I remember that one of the SPs said that since the packet transport network and specifically MPLS-TP intends to replace SONET/SDH we should provide the same capabilities that the customers were used to get in the SONET/SDH networks, even if it is not really necessary.

We should refer to SONET/SDH to see if we can address the capabilities in MPLS-TP.

This was also the motivation of the ITU-T and this is joint work between ITU-T and IETF.  

From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
Sent: Tuesday, October 21, 2008 19:51
To: 'ext BRUNGARD, DEBORAH A, ATTLABS'; ext David Sinicrope; [email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] Meeting notes from the MEAD meeting 10/15-17/2008

Hi Deborah,

Still I think that the migration from SONET/SDH to packet transport network is one of the big motivation and we should include it. 

Best regards,

Nurit

From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Monday, October 20, 2008 22:22
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext David Sinicrope; [email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] Meeting notes from the MEAD meeting 10/15-17/2008

Hi Nurit,

"We use SONET/SDH in the intro quite a bit. Should we also mention Ethernet and the direction the technology is headed and should we mention light paths?  We don't want to convey that we are trying to redefine SONET.

This should work with packets in G.709.  The introduction is text that was taken from ITU-T on why we are creating these requirements, but we don't want to make presumptions on the technology paths that will be followed."

The concern was why we re-used ITU's statements on SONET/SDH as the benchmark for migrating to packet transport networks - suggesting we should generalize so as to be more future-oriented on (other) transport technologies.

Deborah

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Monday, October 20, 2008 1:58 AM
To: ext David Sinicrope; [email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] Meeting notes from the MEAD meeting 10/15-17/2008

HI,

Thanks for the minutes.

(2) I was surprised to read that " The introduction is text that was taken from ITU-T on why we are creating these requirements". As the writer (also) of most of the introduction, I can tell you that it is not taken from the ITU-T. It was integrated with the text that Ben originally put from the ITU-T. I think it is important to include the motivation in the introduction section and this is something that is common in many of the requirement drafts. If something is missing we should include it as well.

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext David Sinicrope
Sent: Sunday, October 19, 2008 23:25
To: [email-masked]
Subject: [Mpls-interop] Meeting notes from the MEAD meeting 10/15-17/2008

Hi All,

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Oct 2008 19:44:49 +0100

Nurit makes a good point.

> has local scope and identifier. LSP identifier may have local scope

It looks like we actually need to identify:
- where to send the OAM response
- which ME the OAM response applies to

It may be helpful to talk in these terms and only then map to the 
information used.

For example, in a bidirectional LSP, both pieces of information are 
determined by the reverse direction label only.

For unidirectional LSPs, "the full FEC" is needed. That is, as Nurit says, 
we have to identify the LSP for which we need the full <source, dest, tunnel 
id, extended tunnel id, LSP ID> quintuple. In RSVP-TE this *is* the FEC (see 
LSP Ping).

But, given that we may operate OAM on an MPLS-TP link or on an LSP. And that 
we might operate on some LSP segment rather than the whole LSP. Perhaps the 
OAM packets would be best to carry a MEP identifier and an ME identifier 
that is unique in the context of the MEP. Looks like the MEP identifier must 
be a reachable address in the context of the return path - that sounds like 
a DCN IP address (aka node identifier). Implementations might choose to map 
the ME identifier from the LSP identifier 5tuple if they choose.

Cheers,
Adrian

PS If you want to introduce additional requirements based on PWs into this 
discussion, you are very welcome. It is just that they have nothing to do 
with MPLS-TP.

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 21 Oct 2008 23:06:25 +0200

Hello Deborah,

> Within IETF, it would be good to discuss with IP performance wgs.

Yes we (Q5/13) have liaised to Q17/12 the PM requirements already
during the development of G.8114 and in fact also for Y.1731.

> understanding/requirements of what is meaningful for packet networks.

Q9/15 also has liaised on this topic with Q17/12.

The MEF is also very interested in the PM of carrier grade packet
transport.

Regards, Huub.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 21 Oct 2008 17:19:25 -0400

Just to clarify what we are looking to count here. I had a similar
debate when working on the L3 VPN MIB years ago. The confusion was around
what specifically are we interested in counting, and further how its
possible to account for that condition. What I think we want to be counting
here are dropped packets not lost packets. Packets are dropped for a reason,
and the two reasons are generally queuing-related (i.e.: out of queue space
for one reason or another) or that they are received in error (i.e. CRC) and
dropped before they even make it to the queue.  You cannot count packets
that were lost (i.e.: those that were sent but someone never made it into
the interface) at the receiver point because there is nothing to count
within the code that processes the counters. The only way you can count
packets that are lost is to diff the counters on the transmit and receive
sides of the packet transmission path.  So while the latter is possible, I
don't think its something that is practical in general, as it is relatively
expensive to implement, and generally not needed for all but a few special
cases.  The former is definitely covered in the aforementioned G- and MPLS
MIBs.

    --Tom

---

From: Loa Andersson <[email-masked]>
Date: Tue, 21 Oct 2008 23:26:59 +0200

Huub van Helvoort wrote:

<snip>

> a count of the packets sent since the previous OAM PDU with the

so if you use that method it must be clear that there is no way
of translating that to ES or SES - true?

are we planning to do this per LSP?

/Loa
<snip>

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 21 Oct 2008 17:28:38 -0400

I second that. I made that point a couple of times in the design team
meeting
last week. To run 1731 like PM function continuously on TP LSP is not
scaleable.
In addtion, using that to detect the signal degrade and to cut over to
the protect
path is problematic.

/himanshu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Tuesday, October 21, 2008 5:19 PM
To: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: Re: [Mpls-interop] Counting lost packets

    Just to clarify what we are looking to count here. I had a similar
debate when working on the L3 VPN MIB years ago. The confusion was
around what specifically are we interested in counting, and further how
its possible to account for that condition. What I think we want to be
counting here are dropped packets not lost packets. Packets are dropped
for a reason, and the two reasons are generally queuing-related (i.e.:
out of queue space for one reason or another) or that they are received
in error (i.e. CRC) and dropped before they even make it to the queue.
You cannot count packets that were lost (i.e.: those that were sent but
someone never made it into the interface) at the receiver point because
there is nothing to count within the code that processes the counters.
The only way you can count packets that are lost is to diff the counters
on the transmit and receive sides of the packet transmission path.  So
while the latter is possible, I don't think its something that is
practical in general, as it is relatively expensive to implement, and
generally not needed for all but a few special cases.  The former is
definitely covered in the aforementioned G- and MPLS MIBs.

    --Tom

On 10/21/08 5:06 PM, "Huub van Helvoort" <[email-masked]> wrote:

>> As I noted on the other parameters (ES, etc), we are mixing 
>> requirements with legacy concepts/solutions (ES, SES, UAS). First, we

>> need an understanding/requirements of what is meaningful for packet
networks.

---

From: "BOCCI Matthew" <[email-masked]>
Date: Wed, 22 Oct 2008 11:43:43 +0200

I think we need to answer the question of how many (or what proportion
of) MPLS-TP LSPs this would need to be applied to. I assume this is only
a small sub-set.

In any case, I'm not sure that answer would be any different if you ask
this for 1731 or for MPLS-TP. 

Matthew

> [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: 21 October 2008 22:29
> To: Thomas D. Nadeau; [email-masked]; BRUNGARD, DEBORAH 
> A, ATTLABS
> I second that. I made that point a couple of times in the 
> design team meeting last week. To run 1731 like PM function 
> continuously on TP LSP is not scaleable.
> In addtion, using that to detect the signal degrade and to 
> cut over to the protect path is problematic.
> 
> /himanshu
> 
>     Just to clarify what we are looking to count here. I had 
> a similar debate when working on the L3 VPN MIB years ago. 
> The confusion was around what specifically are we interested 
> in counting, and further how its possible to account for that 
> condition. What I think we want to be counting here are 
> dropped packets not lost packets. Packets are dropped for a 
> reason, and the two reasons are generally queuing-related (i.e.:
> out of queue space for one reason or another) or that they 
> are received in error (i.e. CRC) and dropped before they even 
> make it to the queue.
> You cannot count packets that were lost (i.e.: those that 
> were sent but someone never made it into the interface) at 
> the receiver point because there is nothing to count within 
> the code that processes the counters.
> The only way you can count packets that are lost is to diff 
> the counters on the transmit and receive sides of the packet 
> transmission path.  So while the latter is possible, I don't 
> think its something that is practical in general, as it is 
> relatively expensive to implement, and generally not needed 
> for all but a few special cases.  The former is definitely 
> covered in the aforementioned G- and MPLS MIBs.
> 
>     --Tom
> 
>

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 22 Oct 2008 11:57:12 +0200

Hello Tom,

> cases.  The former is definitely covered in the aforementioned G- and MPLS

Dropping and discarding packets can happen at any node in an LSP,
however how does the egress node of an LSP know how many packets
are dropped/discarded? The packets dropped/discarded do not
arrive there, so they are "lost".

If the number of lost packets crosses a threshold a protection
switch can be initiated based on this degradation.

The nodes where the packets are dropped/discarded can raise an
alarm for fault localisation.

Counting lost packets is practical in case of protection
switching.

Cheers, Huub.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Oct 2008 08:22:19 -0400

> arrive there, so they are "lost".

    Its possible if you count the number you sent at the ingress and
received at the egress and then subtract those two numbers.  The problem is
in actually implementing this, as it is not as trivial as it might first
sound. *)
 
> switch can be initiated based on this degradation.

    Crossing a threshold or counting a value is the same math calculation;
again its not doing the final subtraction that is difficult its getting the
two numbers.
 
> alarm for fault localisation.

    In *theory* that might make sense, but in a *real* network such as the
ones I run where there are 100s of LSRs and potentially 100,000s of
thousands of LSPs it definitely does not. Remember that MPLS-TP LSPs can
coexist on LSRs that possibly are attached to "classic" MPLS networks.  We
must not continue examining MPLS-TP in a vacuum.

> Counting lost packets is practical in case of protection

    It depends on what you want to count.

    --Tom

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 22 Oct 2008 08:03:39 -0500

Tom,

	Counting sent "packets" at ingress and received "packets" (where
"packets" might also be "frames") at egress is essentially what has been
suggested - using OAM to carry "I-Sent-Since-Last-I-Told-You" messages.

	Lost packets/frames is what is needed for verification of "Loss"
sensitive services.  Arguably, this is analogous to "dropped" under some
conditions, but inferring "lost" packets/frames can be very difficult -
as any number of people have already said - based on per-hop dropped PDU
statistics.  As Huub implied in earlier mail, this becomes MUCH more non
trivial if there is protection switching involvement, since the numbers
that apply have to be inferred from the "active" path forwarding.

	For protected loss-sensitive services, nobody really cares how
many
packets/frames were dropped at any point, or on any path - as long as
all 
of them get through.

	Using an OAM approach is much less difficult than any mechanism
that
uses packet drop statistics, since the information needed is strictly 
"I-Sent"/"You-Received" - independent of particular paths over which the

packets/frames were actually carried.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, October 22, 2008 8:22 AM
> To: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Oct 2008 14:12:26 +0100

So there are some implicit requirements here that need to be stated if we 
want to compare sent and received packet counts.

OAM packets MUST be delivered to the target MEP or MIP in the same relative 
order compared with data packets on the managed entity.

Further we also have...

OAM packets MUST be processed completely on receipt before any further data 
packets are forwarded or counted as received on the managed entity.

If you want the function that Huub and Eric describe, I think you need these 
requirements. But I am not at all sure you really want those requirements!

A

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Oct 2008 09:13:48 -0400

> packets/frames were actually carried.

    Your approach would work as well, but the processing required or the
code/hardware required to process it does not come for free, especially at
wire/fiber speeds. The mechanism, while mostly there in the way of BFD/VCCV,
but would need tweaking. Since MPLS-TP is supposed to be backwards
compatible with classic MPLS as much as possible (IMHO it should be a proper
sub-set), we should fold it back into the base for use there too.

    --Tom

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 22 Oct 2008 08:30:35 -0500

Adrian,

	Then you should probably participate in activities outside
of the IETF.  :-)

	If we would like to consider providing MEF defined services
- for example - using MPLS-TP, then we need to be able to count
"lost" frames.  This may occur at a layer above MPLS-TP, but it
must occur somewhere.

	Note that - if you're looking for loss statistics of the 
order required for some loss-sensitive applications (where - for
example - the loss ratio needs to be below 10^(-6)), you can play
interesting statistical games with the count interval to get an
acceptable estimate of the actual losses that is accounted for in
the desired loss ratio - irrespective of whether or not a single
frame is (or is not) part of the count.

	However, for some "loss-sensitive" applications, delivery
that is out of order is indistinguishable from non-delivery (go
back to the days of SNA, for example).  If in-order delivery is
part of the service, and OAM PDUs go with the service, then we're
all set.

	I can far better understand the argument that MPLS-TP does
not (itself) provide this capability, then I can the argument that
we'll just have to figure out how to do the same thing with drop
statistics.  That argument is lame (as in badly crippled, nearly
DOA).

--
Eric Gray
Principal Engineer
Ericsson  

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Wednesday, October 22, 2008 9:12 AM
> To: Eric Gray; Thomas D. Nadeau; [email-masked]
> Importance: High

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Oct 2008 14:39:09 +0100

Well Eric,

This is a good example of the need to write requirements carefully.

You have rephrased Huub's requirement as:

It must be possible to derive a good approximation of the difference between 
the number of sent packets and received packets.

That requirement, as you say, allows for some guesswork based on an 
understanding of line speed, data rate, and OAM processing time. It is a lot 
easier to achieve.

A

> Then you should probably participate in activities outside

You may be aware that *I* do have a life outside the IETF.

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Wed, 22 Oct 2008 09:28:43 -0500

Hi Deborah,

This is for your information about other PM parameters such as ES, SES,
& UAS for packet networks. 

Y.1563 (Ethernet Frame Transfer and Availability Performance) does
define SES and UAS for verifying Ethernet service availability. Y.1563
is developed by SG12. It is currently in LC comment resolution stage.
But none of the submitted comments is about SES and UAS.

Regards,
Kam

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A,
ATTLABS
Sent: Monday, October 20, 2008 4:35 PM
To: [email-masked]; Adrian Farrel
Cc: [email-masked]
Subject: Re: [Mpls-interop] Counting lost packets

Deborah 

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

Hi Adrian,

Thanks,

Regards, Huub.

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 22 Oct 2008 10:57:10 -0400

Hi Kam,

I was questioning if these PM parameters have been discussed wrt MPLS
networks? While it may be an interesting discussion, there are no
requirements other than it is supported by other technologies. If that's
the requirement, then that's it. But it's not based on MPLS SLAs,
applications, etc.
Deborah 

-----Original Message-----
From: Lam, Hing-Kam (Kam) [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:29 AM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]; [email-masked]; Adrian Farrel
Subject: RE: [Mpls-interop] Counting lost packets

Hi Deborah,

Regards,
Kam

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

Deborah 

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

Hi Adrian,

Thanks,

Regards, Huub.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Oct 2008 17:21:33 +0200

All,

I'm convinced that we need to figure out an appropriate reporting
structure for each data plane technology on its own merits

exactly how is a dropped/discarded/lost packet translated into
ES, SES or UAS?

/Loa

-- 
Loa Andersson

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 22 Oct 2008 11:59:37 -0400

1731 talks about exchanging stats in CCM packets to detect loss as a
proactive method.
Rest of PM tests are on-demand, as far as I know.

Even for 1731-like proactive loss measurement method, keeping of stats
to detect 
signal degrade threshold for fail-over decision, which in turn has
tighter time
limits,  could be difficult even for a small subset, IMO.

In general, we should reconsider requirement for failover on SD or fence
it for very 
limited cases...

/himanshu

-----Original Message-----
From: BOCCI Matthew [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 5:44 AM
To: Shah, Himanshu; Thomas D. Nadeau; [email-masked]; BRUNGARD,
DEBORAH A, ATTLABS

Matthew

> To: Thomas D. Nadeau; [email-masked]; BRUNGARD, DEBORAH A, 
> ATTLABS
> meeting last week. To run 1731 like PM function continuously on TP LSP

> is not scaleable.

> the protect path is problematic.
> 
> /himanshu
> 

> debate when working on the L3 VPN MIB years ago.
> The confusion was around what specifically are we interested in 
> counting, and further how its possible to account for that condition. 
> What I think we want to be counting here are dropped packets not lost 
> packets. Packets are dropped for a reason, and the two reasons are 
> generally queuing-related (i.e.:
> out of queue space for one reason or another) or that they are 
> received in error (i.e. CRC) and dropped before they even make it to 
> the queue.
> You cannot count packets that were lost (i.e.: those that were sent 
> but someone never made it into the interface) at the receiver point 
> because there is nothing to count within the code that processes the 
> counters.
> The only way you can count packets that are lost is to diff the 
> counters on the transmit and receive sides of the packet transmission 
> path.  So while the latter is possible, I don't think its something 
> that is practical in general, as it is relatively expensive to 
> implement, and generally not needed for all but a few special cases.  
> The former is definitely covered in the aforementioned G- and MPLS 
> MIBs.
> 
>     --Tom
> 
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Oct 2008 17:46:02 +0200

Huub,

Huub van Helvoort wrote:

<snip>

I tried to ask what i thought were two rather simple
questions

- the granularity of the packet counting, will it for example
  be done per LSP

- what is reported by the NMS once we know that packets been
  lost - will we try to translate it into ES or SES?
  -- of so why would we need to do that?

> > arrive there, so they are "lost".

from this I draw the conclusion, that the mechanism you proposed
will be needed on a per LSP basis and that you also say below that
it could be used as trig ger a protection action

Let us assume that the packet that carries "sent since last" info
if 50 bytes, sent every 10th ms and we have 2000 LSPs

If I got the numbers right this means

(50 x 8 (# bits in one packet) x (100 (# packets per second))
x 2000 (# of LSPs) = 80 000 000 bit/s (80 Mbit/s)

almost 10% of the traffic on a GE link is used for protection
switching, I've no idea how much traffic is generated by the
rest of the OAM functions

There is possibly other more efficient ways of doing this, but this
one seems to not be very well adapted to trigger protection
actions

... and I'm not too concerned about the generated traffic, but
more om the load this will generate in CPUs or device processors,
not to talk about that we'll have counters programmable on a
per LSP basis

/Loa

-- 
Loa Andersson

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Wed, 22 Oct 2008 14:09:56 -0500

Hi Deborah,

ITU-T requirements on these PM parameters for packet transport networks
are specified in G.7710 (7/2007). Packet transport technologies covered
by the 7/2007 revision of G.7710 explicitly include Ethernet and T-MPLS.
While we are now working on MPLS-TP, however the needs and requirements
of these PM parameters are still legitimate.

Regards,
Kam

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:57 AM
To: Lam, Hing-Kam (Kam)
Cc: [email-masked]; [email-masked]; Adrian Farrel
Subject: RE: [Mpls-interop] Counting lost packets

Hi Kam,

-----Original Message-----
From: Lam, Hing-Kam (Kam) [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:29 AM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]; [email-masked]; Adrian Farrel
Subject: RE: [Mpls-interop] Counting lost packets

Hi Deborah,

Regards,
Kam

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

Deborah 

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

Hi Adrian,

Thanks,

Regards, Huub.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Oct 2008 21:49:34 +0200

Kam,

the problem is not where and how things are specified. What I'm
asking for is the exact method to convert the knowledge of lost/
dropped/discarded packets to the ES, SES and UASes that the NM
requirement spec says is a must:

        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.
(from section 7.1)

Why not use packet network friendly metrics?

Also, we did not say that all the requirements come from ITU-
documents, what we said was that we needed to document in a
series of drafts/RFCs the requirements in such a way that it
is possible to meet them in an MPLS network that runs the
transport profile.

/Loa

-- 
Loa Andersson

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Oct 2008 16:04:06 -0400

> is possible to meet them in an MPLS network that runs the

    Yep, agree with you %100. We should be building things that make
sense, not just taking requirements verbatim.

    --Tom

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Oct 2008 16:16:32 -0400

>Given this, I

This is very good, but we need to make sure that this is reflected in 
the definition of the "standard management interface" required by the 
current requirements drafts...

Lou

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Wed, 22 Oct 2008 15:50:52 -0500

Hi Loa,

What I tried to say is that:

* The needs of these PM parameters are legitimate (please see the JWT
v22 slide 111 on the ITU-T PM objectives)

* Once the OAM PM primitives (such as numbers of packet sent and packet
received) are available, one will be able to calculate the packet loss
ratio. From the ratio, one will be able to determine a one-second period
is ES or SES or not. From SES, one will be able to determine the UAS.

* Method has been specified in Y.1563 for Ethernet. 
For example, in Section 9.2 of Y.1563:
"A Severe Errored Second (SESETH) outcome occurs for a block of frames
observed during a one second interval at ingress MP0 when the
corresponding FLR (i.e. the ratio of lost frames to total frames in the
block) at egress MPi exceeds s1. ...."

* We should apply the similar method for MPLS-TP so that we can
management both packet networks similarly.

Exact wording of these requirements in the MPLS-TP drafts will still
need to be craft out (revised), including modification to the current
requirements in section 7.1 of the NM Requirement draft, as we noted in
the Boston meeting.

Regards,
Kam

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 4:04 PM
To: Loa Andersson; Lam, Hing-Kam (Kam)
Cc: [email-masked]
Subject: Re: [Mpls-interop] Counting lost packets

    --Tom

>> As I noted on the other parameters (ES, etc), we are mixing
requirements

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:12:49 +0200

I think we need to define objects to support OAM entities and functions,
protection domains and functions e.g. linear protection, etc.)
We need to define MIBs to establish TCs :-)
Etc. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Lou Berger
Sent: Wednesday, October 22, 2008 22:17
To: Thomas D. Nadeau
Cc: [email-masked]
Subject: Re: [Mpls-interop] MIBs and PVCs

Lou