Subject: [Mpls-interop] thoughts on NM - many steps back :)

From: Loa Andersson <[email-masked]>
Date: Wed, 19 Mar 2008 15:23:15 +0100

Malcolm,

I don't quite follow the argument about the SONET/SDH-like management
for a transport profile of mpls.

ITU-T folks has spent great energy to explain that a t-mpls network is
a layer network and as such form a network with (the possibility to
have) all the characteristics of transport network.

Now the t-mpls layer network is a packet switched connection oriented
where OAM needs to match these packet switched characteristics, as the
OAM is interdependent on the NM, my conclusion is that NM also needs to
match the packet switched characteristics.

Now there is also a dependency of server and client layer networks.
However this dependencies should be non-dependent of the client and
server layer network characteristics, i.e. the server and client
layer networks might be of different kinds, that we have no possibility
to predict.

Today the ITU-T have a circuit switched generic document G.7710, if
there is a even more generic document G.xxxx and a generic document
for packet switched layer networks G.yyyy the relationship between the
documents should be

                          +-----------+
                          |  G.xxxx   |
                          +-----------+
                               |  |
                     +---------+  +---------+
                     |                      |
               +-----------+         +-----------+
               |  G.7710   |         |  G.yyyy   |
               +-----------+         +-----------+
                     |                      |
               +-----------+         +-----------+
               |G.784 et.al|         |  G.8151   | (there should probably
               +-----------+         +-----------+  more documents on
                                                    this level)

This way you would avoid putting the CS glasses on when writing NM for
packet switched network.

Correct???

/Loa

-- 
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: "Drake, John E" <[email-masked]>
Date: Wed, 19 Mar 2008 13:18:58 -0700

Loa,

I think you're correct, OAM for connection oriented packet switching is
different than OAM for connection oriented circuit switching.  This is a
point that our good friend Neil Harrison has made not more than several
thousand times.

Thanks,

John 

>-----Original Message-----
>From: Loa Andersson [mailto:[email-masked]] 
>Sent: Wednesday, March 19, 2008 7:23 AM
>To: Malcolm Betts; [email-masked]
>Subject: [Mpls-interop] thoughts on NM - many steps back :)
>
>Malcolm,
>
>I don't quite follow the argument about the SONET/SDH-like 
>management for a transport profile of mpls.
>
>ITU-T folks has spent great energy to explain that a t-mpls 
>network is a layer network and as such form a network with 
>(the possibility to
>Now the t-mpls layer network is a packet switched connection 
>oriented where OAM needs to match these packet switched 
>characteristics, as the OAM is interdependent on the NM, my 
>conclusion is that NM also needs to match the packet switched 
>characteristics.
>
>However this dependencies should be non-dependent of the 
>client and server layer network characteristics, i.e. the 
>server and client layer networks might be of different kinds, 
>that we have no possibility to predict.
>
>Today the ITU-T have a circuit switched generic document 
>G.7710, if there is a even more generic document G.xxxx and a 
>generic document for packet switched layer networks G.yyyy the 
>relationship between the documents should be
>
>
>                          +-----------+
>                          |  G.xxxx   |
>                          +-----------+
>                               |  |
>                     +---------+  +---------+
>                     |                      |
>This way you would avoid putting the CS glasses on when 
>writing NM for packet switched network.
>
>Correct???
>
>/Loa
>
>
>--
>Loa Andersson
>

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 19 Mar 2008 15:55:27 -0500

Looking at the ITU Rec's, I noted a recent one (2007) on MPLS Management
and OAM Framework:
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Y.1714-200701-I!!
PDF-E&type=items

It provides an approach combining ITU and IETF OAM work. It wasn't
referenced in G8113, though it seems like it would have been a good
starting point for TMPLS. Malcolm, do you know why? Or is TMPLS by
definition starting with G784 (should we do a flip of Loa's diagram)?
Will Y1714 also be withdrawn?

Deborah

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Drake, John E
Sent: Wednesday, March 19, 2008 4:19 PM
To: Loa Andersson; Malcolm Betts; [email-masked]
Subject: Re: [Mpls-interop] thoughts on NM - many steps back :)

Loa,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 19 Mar 2008 14:28:07 -0700

Deborah,

What is G784?  Neil had indicated to me that T-MPLS re-used Ethernet's
recently developed OAM rather than MPLS OAM, for no particularly good
reason.  Is this consistent with your understanding?

Thanks,

John  

>From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
>Sent: Wednesday, March 19, 2008 1:55 PM
>To: Drake, John E; Loa Andersson; Malcolm Betts; [email-masked]
>Subject: RE: [Mpls-interop] thoughts on NM - many steps back :)
>
>Looking at the ITU Rec's, I noted a recent one (2007) on MPLS 
>Management and OAM Framework:
>It provides an approach combining ITU and IETF OAM work. It 
>wasn't referenced in G8113, though it seems like it would have 
>been a good starting point for TMPLS. Malcolm, do you know 
>why? Or is TMPLS by definition starting with G784 (should we 
>do a flip of Loa's diagram)?
>I think you're correct, OAM for connection oriented packet 
>switching is different than OAM for connection oriented 
>circuit switching.  This is a point that our good friend Neil 
>Harrison has made not more than several thousand times.
>
>Thanks,
>
>John 
>
>network is 
>>server layer network characteristics, i.e. the server and 
>client layer 
>>networks might be of different kinds, that we have no possibility to 
>>predict.
>>
>>there is a even more generic document G.xxxx and a generic 
>document for 
>>packet switched layer networks G.yyyy the relationship between the 
>>documents should be
>>
>>
>>                          +-----------+
>>                          |  G.xxxx   |
>>                          +-----------+
>>                               |  |
>>                     +---------+  +---------+
>>                     |                      |

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 20 Mar 2008 07:56:48 -0400

We might want to ask him directly, but I know for sure that the folks
here do not appreciate Y1731.

    --Tom

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 20 Mar 2008 08:41:41 -0400

Tom, my understanding is that the concerns that Neil has on Y.1731 are
the extensions that it makes to 802.1ag.  To over simplify, these
extension attempt to apply connection oriented "metrics" (e.g. AIS) to a
connectionless technology.  Ironically, these extensions may be more
applicable to T-MPLS (since it is connection oriented).

On the issue of reuse of Y.1731/802.1ag OAM, the transport network is
multi technology so if we have the same function using the same OAM
"payload" has advantages in simplifying network management and
interworking.  We must balance that against compatibility with existing
MPLS techniques.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.

> From: Thomas Nadeau [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 7:57 AM
> To: Drake, John E; BRUNGARD, DEBORAH A, ATTLABS; Loa 
> Anderson; Betts, Malcolm (CAR:X632); [email-masked]
>     We might want to ask him directly, but I know for sure 
> that the folks here do not appreciate Y1731.
> 
>     --Tom
> 
>     
> > Deborah,
> > 
> switching 
> >> is different than OAM for connection oriented circuit switching.  
> >> This is a point that our good friend Neil Harrison has 
> made not more 
> >> than several thousand times.
> >> 
> >> Thanks,
> >> 
> >> John
> >> 
> >> characteristics, as the
> client and 
> G.7710, if

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Mar 2008 13:06:01 -0000

Malcolm,

Can you clarify your "multi-technology" statement for me?

Superficially, I agree. There are multiple technologies used to deliver 
traffic end to end in a transport network.

The question for me is whether those technologies are horizontally or 
vertically integrated. To use a fatuous example (for the sake of clarity) I 
may have an IP payload that I want to deliver across a transport network. 
Part of that network may be Ethernet, and part MPLS (forget T-MPLS versus 
MPLS ;-).

Suppose that the entry point to the transport network is MPLS capable. I 
perform adaptation to MPLS (simple imposition of an MPLS shim) and forward 
through the MPLS part of the network until I reach the Ethernet part. Now I 
have two choices:
1. Terminate the MPLS trail returning to the payload signal type and start 
an new trail for the Ethernet part of the network. Use IP over Ethernet 
encapsulation/adaptation.
2. Adapt the MPLS signal over Ethernet and deliver IP over MPLS over 
Ethernet.

As far as I can see both of these solutions fit within the architecture, but 
have very different consequences for "end-to-end" OAM.

In the first case, there is no end-to-end transport trail. The transport 
network is partitioned, and we must consider carefully whether the 
"stitching point" is considered to be in the client network.

In the second case, there is potential for end-to-end OAM, but we should 
note that this is a layered solution and the end-to-end connectivity is in 
the MPLS layer only. Ethernet OAM may be operated, but it will only provide 
function in the Ethernet layer, and may provide "advice" to the MPLS layer.

Oh! That was a long question :-)

Adrian

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 20 Mar 2008 09:32:42 -0400

Adrian, an interesting question - see in line below.

Malcolm Betts
Nortel Networks

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Thursday, March 20, 2008 9:06 AM
> To: [email-masked]
> Superficially, I agree. There are multiple technologies used 
> to deliver traffic end to end in a transport network.
> 
> The question for me is whether those technologies are 
> horizontally or vertically integrated. To use a fatuous 
> example (for the sake of clarity) I may have an IP payload 
> that I want to deliver across a transport network. 
> Part of that network may be Ethernet, and part MPLS (forget 
> T-MPLS versus MPLS ;-).
> 
> Suppose that the entry point to the transport network is MPLS 
> capable. I perform adaptation to MPLS (simple imposition of 
> an MPLS shim) and forward through the MPLS part of the 
> network until I reach the Ethernet part. Now I have two choices:
> 1. Terminate the MPLS trail returning to the payload signal 
> type and start an new trail for the Ethernet part of the 
> network. Use IP over Ethernet encapsulation/adaptation.
> 2. Adapt the MPLS signal over Ethernet and deliver IP over 
> MPLS over Ethernet.
You have described two different services: the first is delivering
IP and since IP does not support monitoring this is essentially
a "best effort" non guaranteed service.  The second example is
delivering MPLS.  If I chose to implement this MPLS service
using the transport profile (aka T-MPLS) then the user can
invoke OAM and monitor the service, so can the operator.
This gives the basis for a "guaranteed service" i.e. meet the
metrics or the user gets a refund.

> 
> As far as I can see both of these solutions fit within the 
> architecture, but have very different consequences for 
> "end-to-end" OAM.
> 
> In the first case, there is no end-to-end transport trail. 
> The transport network is partitioned, and we must consider 
> carefully whether the "stitching point" is considered to be 
> in the client network.
Agree, the stitching point is in the client layer.
> 
> In the second case, there is potential for end-to-end OAM, 
> but we should note that this is a layered solution and the 
> end-to-end connectivity is in the MPLS layer only. Ethernet 
> OAM may be operated, but it will only provide function in the 
> Ethernet layer, and may provide "advice" to the MPLS layer.
Agree and this is where the "vertical" multi technology applies
because both Ethernet and MPLS may ride over GFP/SDH/OTN etc.
Further point having consistent metrics in MPLS and Ethernet
simplifies fault correlation (and I may not activate the client
layer (MPLS) measurements if I am running Ethernet under it.

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 20 Mar 2008 09:41:12 -0400

Loa, your email and the discussion we had on Tuesday provoked some
further thoughts.  I will post these thoughts on the JWT list as well to
get other thinking about these issues.

I agree that G.7710 is heavily biased towards circuit switching, this
needs to be addressed, not sure if we need a new Recommendation.  But I
am convinced that this does not impact the option 1/2 considerations (as
long as we recognize the bias).

I have also attached the text below as a word document since it is
easier to read with the formatting.

We have a number of things in the area of OAM and Network Management
that we need to separate.

OAM vs. Network Management
Management interface on an IP box vs. on a Transport box
Service assurance vs. Infrastructure maintenance
Packet vs. circuit measurement techniques

First a quick overview of the background/requirements for packet
transport.  

Packet transport is intended to provide finer/more flexible service
granularity than that offered by a circuit switched transport network.
It must fit into the OSS infrastructure and operation processes of the
existing transport network.  The transport network is multi carrier,
multi technology and multi vendor.  One of the key requirements is that
each carrier can verify that the service being provided meets the terms
of the contract.  Also each carrier must be able to run and maintain its
network independent of other carriers.  This drives a need for isolation
of recovery action - the transport operation processes dictate use of
protection.

This summary does not replace the detailed requirements that may be in
many of the documents discussed at the T-MPLS ad hoc meeting, these are
available from: 
http://ties.itu.int/ftp/public/itu-t/ahtmpls/readandwrite/doc_exchange/0
802_geneva/

OAM vs. Network management

OAM does the detection; Network Management does the reporting and
logging.
OAM (east west) is used to observer/monitor the transfer of information
between the source and the destination.  OAM is used to detect
"anomalies" that are integrated into "defects" and passed to network
management.
ITU Network Management:  Network management (on the box) may count
defects (e.g. for performance management) and further integrates them
into "alarms".  It is also responsible for the configuration of the box.
Performance management: Defects in a period are counted in bins, 15
minute and 24 hour bins are used.  Only threshold crossings are reported
i.e. when the number of defects counted in a period exceeds the
threshold.  The contents of the bins may be collected periodically -
typically some form of data compression is used (e.g. bins with "0"
counts are not sent).
Alarms are subject to an "alarm reporting control function", this
determines if a notification should be sent.
All notifications (alarms and PM threshold crossings etc.) are logged.

Network Management of an IP box vs. a Transport box

We (I) need to avoid the temptation of attempting to "boil the ocean".
In some future ideal world we should have a single network management
interface for all boxes.  This implies that we also have a coherent
network model.
IP routers with SDH/OTN interfaces have been deployed.  The IP boxes and
Transport boxes deployed in the network today use different management
interfaces (and different network models).  I suggest that our objective
is to achieve parity with current capabilities.  In practice this means:
*	OAM must use the same mechanisms and report the same defects.
*	Network management must provide equivalent alarms/notifications
and:
*	Provide equivalent configuration capabilities for the common
parts.

Service assurance vs. Infrastructure maintenance

In the circuit switch world we have a limited set of tools that are used
for both and hence we tend to blur/ignore the distinction between
service assurance and infrastructure maintenance.  Also in the circuit
switched world anomalies/defects in the server (lower) layers result in
the same defect/anomaly in the client layer, which are directly detected
using the same tools.

When the client is packet switched things are different:
*	The anomalies in the circuit switched server (lower) layer (e.g.
an error burst) may not be directly observed since the packet to circuit
adaptation function typically discards frames with errors.
*	The capabilities of the packet based tools are different - e.g.
detection of lost frames may be difficult.
*	Frames may be discarded because of network congestion.  This can
be observer directly by counting frames discarded by buffers and avoided
by observing buffer fill (and triggering a request for additional
resources).
Infrastructure maintenance can be performed by directly observing server
(lower) layer defects and packet buffer fill/ spills.  These indications
are only available within a single operator domain.  They provides a
"reasonable" estimate of the "quality of service" provided by the
network.  These infrastructure metrics do not provide a direct
measurement of the performance of specific instance of a service.  This
is acceptable for a "best effort" service.
When guaranteed services are offered both the service provider and the
end customer must be able to directly measure the service against the
contract.  This is particularly important when the service transits the
network of more than one carrier.  Direct measurement/observation in the
(packet) client layer is required when the service transits one or more
packet switching nodes in the service providers network.

Packet vs. Circuit measurement techniques

In a circuit switched network the connection metrics are the
availability and the number of errored seconds, and severely errored
seconds (usually per month).  A connection is declared to be unavailable
after 10 severely error seconds and becomes available after 10 error
free seconds.  Persistent faults are detected by the bit error rate or
loss of frame.  Intermittent (or burst errors) are recorded by PM counts
and reported as threshold crossing alerts.  These measurements can be
can be made directly on both the infrastructure and the service.  The
limited flexibility of circuit switching may require the use of TCM
(Tandem connection monitoring) to isolate faults between network
operators.

In a packet switched transport network the potential metrics are
availability, number of lost frames and delay variation.  It should be
noted that 802.1ag/Y.1731 offer techniques for providing a "reasonable
estimate" of these metrics.

Malcolm Betts
Nortel Networks

> Sent: Wednesday, March 19, 2008 10:23 AM
> To: Betts, Malcolm (CAR:X632); [email-masked]
> Subject: thoughts on NM - many steps back :)
> 
> Malcolm,
> 
> generic document for packet switched layer networks G.yyyy 
> the relationship between the documents should be
> 
> 
>                           +-----------+
>                           |  G.xxxx   |
>                           +-----------+
>                                |  |
>                      +---------+  +---------+
>                      |                      |

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 Mar 2008 15:19:21 +0000

Malcolm
> estimate" of these metrics.
I have been thinking about this. The reason that (severely) errored 
seconds are so important in connection oriented is that their lineage in 
synchronous transport where the clock recovery systems are 
(hyper)sensitive to loss of clock and losses of frame sync has 
escalating consequences.

In packet systems we have never been as sensitive about that because 
from a data transfer point of view we recover as soon as the physical 
media recovers, because media losses are generally small compared to 
congestion and convergence losses and because until the advent of some 
of the newer applications (TDM PW, high quality streaming TV etc)  
applications we designed to cope with such errors.

This would suggest to me that at the packet transport layer we really 
need packet metrics, but in the case of some PWs (when they are provided 
by the transport network) we need connection metrics. We should 
therefore run the connection metrics over the PWs that care, and indeed 
should tailor the metrics to the PW type.

- Stewart

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 20 Mar 2008 11:37:48 -0400

Stewart, you raise an interesting point.  The real issue is who is
paying for what.  I agree that for most "internet/best effort traffic"
then congestion in the packet layer is a much more serious issue and
internet protocols can (and do) work these "impairments".

However if the network is selling a "transport service" congestion
should not be an issue. Packet transport is intended to be replacement
of a circuit switched service with the same characteristics.  Some of
the most "stringent" customers for transport connections today are using
them for applications such as data base mirroring.  They check the
delivered service against the ES/SES requirements, since packet loss in
the "media" does cause serious problems for these applications.  I
suspect that these customers will expect similar performance when they
buy a "packet transport connection".  These tend to be the low volume
but high value customers.

Malcolm Betts
Nortel Networks

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 11:19 AM
> To: Betts, Malcolm (CAR:X632)
> Cc: Loa Andersson; [email-masked]
> Subject: Re: [Mpls-interop] thoughts on NM - metrics
> 
> Malcolm
> >
> > seconds (usually per month).  A connection is declared to be 
> > unavailable after 10 severely error seconds and becomes available 
> > after 10 error free seconds.  Persistent faults are detected by the 
> > bit error rate or loss of frame.  Intermittent (or burst 
> errors) are 
> > recorded by PM counts and reported as threshold crossing alerts.  
> > These measurements can be can be made directly on both the 
> > infrastructure and the service.  The limited flexibility of circuit 
> > switching may require the use of TCM (Tandem connection 
> monitoring) to 
> > isolate faults between network operators.
> >
> I have been thinking about this. The reason that (severely) 
> errored seconds are so important in connection oriented is 
> that their lineage in synchronous transport where the clock 
> recovery systems are (hyper)sensitive to loss of clock and 
> losses of frame sync has escalating consequences.
> 
> In packet systems we have never been as sensitive about that 
> because from a data transfer point of view we recover as soon 
> as the physical media recovers, because media losses are 
> generally small compared to congestion and convergence losses 
> and because until the advent of some of the newer 
> applications (TDM PW, high quality streaming TV etc) 
> This would suggest to me that at the packet transport layer 
> we really need packet metrics, but in the case of some PWs 
> (when they are provided by the transport network) we need 
> connection metrics. We should therefore run the connection 
> metrics over the PWs that care, and indeed should tailor the 
> metrics to the PW type.
> 
> - Stewart
> 
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Mar 2008 18:13:56 -0000

I'm getting out of my area, but...

> should not be an issue.

This is completely true.

Except...  :-)

- Packet transport gives the service provider the ability to
  attempt to squeeze more customers into their network. They
  can apply statistical agregation schemes without their customers'
  knowledge. Or they can sell price-differentiated services. If
  the technology allows it, I don't see that we can prevent or
  preclude. We can, however, make it easy or messy.

- In a circuit-based transport network, you can buy several
  grades of reslience and these are usually realised through
  protection and recovery schemes such as 1+1, 1:1, 1:m, and
  restoration. The packet transport network offers an additional
  realisation mechanism - statistical resource sharing. This might
  be applied, for example, to provide "instant" recovery before
  restoration. The quality of the recovery path might not be
  up to the quality of the primary path, but this is still better than
  waiting for the restoration path.

I think a really big mistake is to say that tomorrow's transport network 
must be limited to the functions of today's transport network. Clearly we 
need to migrate all existing functions, but why would we constrain the 
operator to not take advantage of new technologies?

Cheers,
Adrian

---

From: Ron Bonica <[email-masked]>
Date: Thu, 20 Mar 2008 16:45:26 -0400

Malcolm,

I am curious about your claim that T-MPLS is connection oriented.
Although I can't find an RFC that addresses the issue, I think of MPLS
as being connectionless.

Can you explain how you conceptualize T-MPLS as connections?

                                   Ron

Malcolm Betts wrote:
>>>What is G784?  Neil had indicated to me that T-MPLS re-used 
>>
>>Ethernet's 
>>
>>>recently developed OAM rather than MPLS OAM, for no 
>>
>>particularly good 
>>
>>>>referenced in G8113, though it seems like it would have 
>>
>>been a good 
>>
>>>>definition starting with G784 (should we do a flip of 
>>
>>Loa's diagram)?
>>
>>>>>a layer network and as such form a network with (the 
>>
>>possibility to
>>
>>>>>OAM is interdependent on the NM, my conclusion is that NM
>>>>
>>>>also needs to
>>>>
>>>>>Now there is also a dependency of server and client layer 
>>
>>networks.
>>
>>>>>networks might be of different kinds, that we have no 
>>
>>possibility to 
>>
>>>>>predict.
>>>>>
>>>>>packet switched layer networks G.yyyy the relationship 
>>
>>between the 
>>
>>>>>documents should be
>>>>>
>>>>>
>>>>>                         +-----------+
>>>>>                         |  G.xxxx   |
>>>>>                         +-----------+
>>>>>                              |  |
>>>>>                    +---------+  +---------+
>>>>>                    |                      |
>>>>>              +-----------+         +-----------+  more 
>>
>>documents on
>>
>>>>>                                                   this level)
>>>>>
>>>>writing NM for

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 20 Mar 2008 17:09:47 -0400

Adrian, I agree, I intended to state that some operators wish to
run/engineer the network in a way that avoids congestion and hence can
offer "guaranteed" services.

A reasonable analogy is a trans Atlantic airline.  Some customer are
prepared to pay a premium price for preferential treatment (first class)
the majority will buy based on price (and moan about the service).   The
trick for the airline is to be able to offer the premium grade (with the
attendant higher margin) without compromising the cost of the "coach
class" offer.

Malcolm Betts
Nortel Networks

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 2:14 PM
> To: Betts, Malcolm (CAR:X632); [email-masked]
> Cc: [email-masked]
> I think a really big mistake is to say that tomorrow's 
> transport network must be limited to the functions of today's 
> transport network. Clearly we need to migrate all existing 
> functions, but why would we constrain the operator to not 
> take advantage of new technologies?
> 
> Cheers,
> Adrian 
> 
> 
>

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 20 Mar 2008 17:09:59 -0400

Ron, I think of connection oriented and connectionless are useful
"bookends" for describing network behaviour.  MPLS falls somewhere in
the middle.

T-MPLS was intended to be a profile of MPLS (the current exercise will
make that a true statement) that excludes some MPLS behaviour (e.g.
label merge) such that it is connection oriented.  Thus, from the
perspective of monitoring and reporting the network behaviour we can
consider it to be connection oriented.  However, we must recognize that
fault conditions may invoke undesired behaviour (e.g. label merge) and
these fault conditions must be detected. 

Malcolm Betts
Nortel Networks

> From: Ron Bonica [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 4:45 PM
> Although I can't find an RFC that addresses the issue, I 
> think of MPLS as being connectionless.
> 
> > extension attempt to apply connection oriented "metrics" 
> (e.g. AIS) to 
> > a connectionless technology.  Ironically, these extensions 
> may be more 
> > interworking.  We must balance that against compatibility with 
> > existing MPLS techniques.
> > 
> > Malcolm Betts
> > Nortel Networks
> > believe that you are not the intended recipient or a person 
> > responsible for delivering this message to an intended 
> recipient, you 
> > are hereby notified that any review, dissemination, 
> distribution, or 
> > copying of this message is strictly prohibited. If you have 
> reason to 
> > believe that you are not the intended recipient or a person 
> > responsible for delivering this message to an intended recipient, 
> > please contact the sender immediately by reply email and 
> destroy all 
> > copies of the original message.
> >  
> > 
> > 
> Anderson; Betts, 
> >>Malcolm (CAR:X632); [email-masked]
> >>    We might want to ask him directly, but I know for sure that the 
> >>folks here do not appreciate Y1731.
> >>
> >>    --Tom
> >>
> >>    
> >>
> >>>Deborah,
> >>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Mar 2008 21:21:04 -0000

Malcolm,

We appear to agree completely (twice in one month? careful!)

It must be possible to guarantee a service level (within the margins of 
failing hardware).

Other grades are also possible.

Cheers,
Adrian
----- Original Message ----- 
From: "Malcolm Betts" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 20, 2008 9:09 PM
Subject: RE: [Mpls-interop] thoughts on NM - metrics

Malcolm Betts
Nortel Networks

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 20 Mar 2008 17:34:22 -0400

I think the confusion around this is that Malcolm assumes TE is CO
(versus CL when you use auto-routed LSPs).

    --Tom