Subject: [mpls-tp] RE R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

From: Maarten Vissers <[email-masked]>
Date: Mon, 29 Nov 2010 07:54:14 +0100

Hi Fei,

Consider a multi-operator PW or service-LSP. Each operator will set up a
SPME to monitor this service in its domain. The SPME MEPs will be located on
the UNI-N and E-NNI ports (Up MEPs). Consider that e.g. the first operator
network has to pass this service through its access, metro and core domains.
The E-NNI port is located in a gateway node connected to the core and the
UNI-N port is located in a NT device in the access domain. A change of path
in e.g the core due to a recovery action (e.g. restoration) is normally
performed without any communication from this domain to the UNI-N or E-NNI
ports outside those domains. As such restoration uses the state of the
Sections or transport-LSPs, there will be normally no SPMEs for each of the
protected services be present at the edge of the core domain.

Regards,

Maarten

From: [email-masked] [mailto:[email-masked]] 
Sent: 29 November 2010 02:20
To: Maarten Vissers
Cc: Dan Frost; BUSI, ITALO (ITALO); John E Drake; [email-masked];
[email-masked]
Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in
draft-ietf-mpls-tp-oam-framework-09

Hi Maarten 

See in line, jut my two cents 

Fei :) 

Maarten Vissers <[email-masked]> 

2010-11-28 19:20 

收件人

"[email-masked]" <[email-masked]> 

抄送

John E Drake <[email-masked]>, Dan Frost <[email-masked]>, "BUSI,
ITALO (ITALO)" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]> 

主题

Re: [mpls-tp] R: Intermediate nodes and segment monitoring in
draft-ietf-mpls-tp-oam-framework-09

John, Fei, 

The MEPs may be located outside the recovery domain, and will be unaware of
the change of the number of hops in their transport path. 

ZF: Firstly, I do not think what you said will happen, for SPME is used for
monitoring and protection. It normally exists between ingress and egress
port of a recovery domain, so it will aware of the hops of working and
protection path.     

There is of course a workaround to get around this issue... I.e set up a
SPME between ingress and egress ports of a recovery domain. You do this by
means of two Up MEPs on those NNI ports, if those are supported in
MPLS-TP... With such SPME either path through the recovery domain will count
as one hop... But this will add further complexity, just because you don't
want to use the currently supported non-standard reading capabilities of
those NNI ports. 

ZF: A recovery domain does not mean that the information of the hops will be
hidden, Even it is located outside the recovery domain (a very little
chance), can also be learned by NMS or Control plane [see RFC4873]. 

Of course,two Up MEPs will work, but why do not use the simplier solution if
it can work? 

Regards, 
Maarten 

Op 28 nov. 2010 om 04:04 heeft [email-masked] het volgende
geschreven:

John: 

I agree with you, but TTL scheme will face scaling issues if it is used for
nested path segment monitoring, as I addressed in
draft-zhang-mpls-tp-path-segment-monitoring-01. 

Fortunately, it would not happen if it is only used for on-demand
monitoring. 

So MBB is used for proactive and TTL used for the on-demand monitoring? This
would utilize the advantages of these two schemes. 

Italo, Dan: 

If TTL is used, two options are applicalbe: 

(1)lifting the restriction on intermediate nodes, as Dan said. 

(2)Increasing the MEP definition for path segment, a little revision to the
document [tp-identifier]. 

Just my two cents. 

Fei :)

---

From: <[email-masked]>
Date: Mon, 29 Nov 2010 10:45:40 +0000

Now consider that each operator is using different addressing, different OAM options, ......what happens now at a receiving trail term pt under misconnectivity when traffic units and OAM that have CI that is not known by that trail term pt arrive there?

Aside=> Same applies to arbitrary nested stacks of LSP sublayering LSP layering

Also in the *MS* PW case (ie true PW layer network) spanning multiple operators:
-    how is routing information distributed between the different operators...esp if they decide to use different access point addressing (let alone different equipment, OSS, network service specifications, etc)?
-    how is signalling and provision of end-end PW paths done?
-    what happens when end-end PW needs to be rerouted across different server layer partitions...esp all the a priori configured TCM spans and any PM monitoring that was being recorded there (eg how is overall PM handled across failures to maintain accuracy in each span?)

Folks who think E-NNIs in any non-TOS layer networks are a good idea clearly like to create unnecessary work and make the life of operators costly and problematic....

Neil Harrison
BT Design

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: 29 November 2010 06:54
To: [email-masked]
Subject: [mpls-tp] RE R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

Hi Fei,

Consider a multi-operator PW or service-LSP. Each operator will set up a SPME to monitor this service in its domain. The SPME MEPs will be located on the UNI-N and E-NNI ports (Up MEPs). Consider that e.g. the first operator network has to pass this service through its access, metro and core domains. The E-NNI port is located in a gateway node connected to the core and the UNI-N port is located in a NT device in the access domain. A change of path in e.g the core due to a recovery action (e.g. restoration) is normally performed without any communication from this domain to the UNI-N or E-NNI ports outside those domains. As such restoration uses the state of the Sections or transport-LSPs, there will be normally no SPMEs for each of the protected services be present at the edge of the core domain.

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]]
Sent: 29 November 2010 02:20
To: Maarten Vissers
Cc: Dan Frost; BUSI, ITALO (ITALO); John E Drake; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

Hi Maarten

Fei :)

2010-11-28 19:20

收件人

抄送

John E Drake <[email-masked]>, Dan Frost <[email-masked]>, "BUSI, ITALO (ITALO)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

主题

Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09

John, Fei,

The MEPs may be located outside the recovery domain, and will be unaware of the change of the number of hops in their transport path.

ZF: Firstly, I do not think what you said will happen, for SPME is used for monitoring and protection. It normally exists between ingress and egress port of a recovery domain, so it will aware of the hops of working and protection path.

There is of course a workaround to get around this issue... I.e set up a SPME between ingress and egress ports of a recovery domain. You do this by means of two Up MEPs on those NNI ports, if those are supported in MPLS-TP... With such SPME either path through the recovery domain will count as one hop... But this will add further complexity, just because you don't want to use the currently supported non-standard reading capabilities of those NNI ports.

ZF: A recovery domain does not mean that the information of the hops will be hidden, Even it is located outside the recovery domain (a very little chance), can also be learned by NMS or Control plane [see RFC4873].

Of course,two Up MEPs will work, but why do not use the simplier solution if it can work?

Regards,
Maarten

Op 28 nov. 2010 om 04:04 heeft [email-masked]<mailto:[email-masked]> het volgende geschreven:

John:

I agree with you, but TTL scheme will face scaling issues if it is used for nested path segment monitoring, as I addressed in draft-zhang-mpls-tp-path-segment-monitoring-01.

Fortunately, it would not happen if it is only used for on-demand monitoring.

So MBB is used for proactive and TTL used for the on-demand monitoring? This would utilize the advantages of these two schemes.

Italo, Dan:

(2)Increasing the MEP definition for path segment, a little revision to the document [tp-identifier].

Just my two cents.

Fei :)