Subject: Re: [mpls-tp] WK Last Call on draft-ietf-mpls-tp-oam-requirements-02.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 06 Jul 2009 18:49:18 +0100

Colleagues,

Below are my comments on draft-ietf-mpls-tp-oam-requirements-02 split into
non-editorial and editorial.

Ben

Non-Editorial

1) Section 1.1. Requirements language, in MPLS-TP Requirements we used the
following text:

   Although this document is not a protocol specification, the key words
   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
   interpreted as described in RFC 2119 [RFC2119] and are to be
   interpreted as instructions to the protocol designers producing
   solutions that satisfy the requirements set out in this document.

Do we want to use the same or similar text in all MPLS-TP requirements
documents?

2) Section 2.1.4 states
   "It is REQUIRED that OAM interoperability is achieved across the
   environments described in Section 2.1.3."

Which seems to imply that we need to specify OAM interoperability between
environments where IP routing & forwarding are present and environments
where they are not.

Is it possible to scope this interoperability requirement so that the
consequences of it are clearer, for example I can see an end to end path may
traverse different "domains" where some domains use IP capability for OAM
and some do not. I think it unlikely to have a mix of such equipment within
a single domain. Furthermore I would expect end to end OAM to have
compatible equipment (IP support or not) at least on the two end points of
the path.

If my view above is shared, then the scope of OAM interoperability is much
reduced as availability of IP for use with OAM is consistent within a domain
and also for the End Points of any End to End OAM flows.

Editorial:

3) Introduction (Page 3) 5th bullet s/meet service/meeting service/

4) Section 2.2.4, there are two occurrences where you need to
s/diagnotic/diagnostic/

5) Throughout the document a mixture of SHALL and MUST is used. Although
they mean the same thing we may want to be consistent and just chose one or
the other.

On 29/06/2009 14:37, "Loa Andersson" <[email-masked]> wrote:

> All,
> 
> This is to start a working group lat call on
> 
> draft-ietf-mpls-tp-oam-requirements-02.txt
> 
> that is is schedule to end July 17th.
> 
> We chosen to start this last call already now and prolong it
> one week since we have a a parallel wg last call on the network
> management requirements (ending July 10).
> 
> Please send comments to mpls-tp mailing list!
> 
> *I.e. do not simply do a reply all on this mail.*
> 
> /Loa
>

---

From: Jia HE <[email-masked]>
Date: Mon, 13 Jul 2009 19:53:28 +0800

Dear All,

Below is my comment on draft-ietf-mpls-tp-oam-requirements-02.txt

Section 2.1.1 states

" The protocol solutions developed to meet the requirements identified
   in this document MUST be applicable to point-to-point bidirectional
   PWs, point-to-point bidirectional LSPs, and point-to-point
   bidirectional Sections and SHOULD additionaly be applicable to
   unidirectional point-to-point and point-to-multipoint LSPs."
   
Is it bidirectional associated or bidirectional co-routed? It is better to state explicitly here and in the latter general requirement part since some OAM functions may have dependency on the type of transport path. 

Besides, it is also beneficial to claim the limitation or additional requirements for OAM functions applied in unidirectional transport path.  

In Section 2.1.3, it describes

 " o  In some environments (e.g., IP/MPLS environments), IP routing and
      forwarding capabilities are inherently present in the forwarding
      plane.  In this case, it MUST be possible to operate the OAM
      functions by relying on IP routing and forwarding capabilities. 

   o  In some environments (e.g., MPLS-TP environments), IP routing and
      forwarding capabilities may not necessarily be present in the user
      plane.  In this case, it MUST be possible to operate the OAM
      functions without relying on IP routing and forwarding
      capabilities.  "

Not quite follow this part...

1) From the title of this section "Addressing, Routing and Forwarding", I'm expecting to read the basic forwarding requirements for MPLS-TP OAM, e.g. how to forward a MPLS-TP OAM packet (based on the outmost forwarding label). But the main part seems to jump into the relationship with IP routing and forwarding. 

2) The first paragraph is talking about a "MUST" requirement in IP/MPLS environment. I'm not sure why it is included in the MPLS-TP OAM requirement? What's the relationship between IP/MPLS environment and MPLS-TP since in the second paragraph MPLS-TP enviroment is mentioned?

3) Clarification on the second paragraph: 
Since we do have scenarios in MPLS-TP environment where IP routing and forwarding is not supported as described, it is therefore a "MUST" in MPLS-TP OAM to develop tool-set without depending on IP forwarding/routing so that it is applicable in all cases (whether there is IP routing/forwarding in the user plane or not).  I'm trying to understand the point and hope it can be clarified. Thanks!

B.R.
Jia

----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; "Ross Callon" <[email-masked]>; "Adrian Farrel" <[email-masked]>
Sent: Monday, June 29, 2009 9:37 PM
Subject: [mpls-tp] WK Last Call on draft-ietf-mpls-tp-oam-requirements-02.txt

> -- 
> Loa Andersson
> Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
> Ericsson ///                                 +46 767 72 92 13
> 
>                                      email:  [email-masked]
>                                              [email-masked]
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Jul 2009 23:17:06 +0200

I have a general comment on the draft.

The document describes high-level functional and architectural
requirements for MPLS-TP OAM. As far as I recall from MEAD discussions,
the intent is not to describe detailed protocol design requirements.

I think it would be useful to clarify this point in the scope of the
draft.

I have also the following detailed comments:

1) Section 2.2.3

I must be possible to perform on-demand Connectivity verification with
different packet sizes in order to verify also MTU problems.

2) Section 2.2.4

I would propose to call it "Diagnostic Test"

3) Section 2.2.10

c/a client defect of/a client defect or/

4) Section 2.2.11

I would propose to call it "Packet Loss Measurement"

5) Section 2.2.12

I would propose to call it "Packet Delay Measurement"

Thanks, Italo

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Monday, June 29, 2009 3:38 PM
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; Ross Callon; Adrian Farrel
> Subject: [mpls-tp] WK Last Call on

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 16 Jul 2009 15:03:36 -0700

> 2.2.1. General Requirements

>   If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST
 >  be provided to detect it, diagnose it, localize it, and notify the
 >  appropriate nodes.  Mechanisms SHOULD exist such that corrective
 >  actions can be taken.

The last sentence above is very general and vague. The "SHOULD" statement should be removed.

>   Furthermore, mechanisms MUST be available for a service provider to
 >  be informed of a fault or defect affecting the service(s) it
 >  provides, even if the fault or defect is located outside of his
 > domain.

The above seems unreasonable. If a service provider needs to detect faults, it
Should run end-to-end OAM and should not rely on some other entity to notify
it of a failure in someone else's domain.

> 2.2.6. Lock Instruct

Please clarify the expected behavior for OAM traffic for locked LSP/PW. I presume OAM traffic
Will still be allowed to go through for locked LSP/PW segments.

> Section 2.2.7: Lock Reporting
> The MPLS-TP OAM toolset MUST provide functionality to enable an
 > Intermediate Point of a PW or LSP to report, to an End Point of that
 > same PW or LSP, an external lock condition affecting that PW or LSP.

Locks are performed at LSP/PW end-points (as per Section 2.2.6). So why do we need an intermediate point
to report regarding the lock condition. Maybe I missed something obvious.

> This function SHOULD be performed pro-actively.

Not clear on what this means. If you lock the end points of a LSP, then the intermediate points should not care,
because they will just stop receiving data. So how is the intermediate point supposed to detect the lock and
Then how is it supposed to inform the LSP end-point pro-actively ?

> Section 2.2.8. Alarm Reporting

If you are running CC, then CC would report the error. If you are not running CC, then alarm reporting helps.
Is that the case that is being asked for?

> 2.2.10. Client Failure Indication

 >  The MPLS-TP OAM toolset MUST provide functionality to enable the
 >  propagation, across an MPLS-TP network, of information pertaining to
 >  a client defect of fault condition detected at an End Point of a PW
 > or LSP, if the client layer OAM mechanisms do not provide an alarm
 > notification/propagation mechanism.

Does this mean that we need a OAM mapping mechanism between MPLS-TP OAM and client OAM?
If so, then it means we need to define a OAM mapping scheme for all client types.

> 2.2.11. Packet Loss
> Note that packet loss ratio is the ratio of the user packets not
> delivered

Does this specifically have to be "user packets" ? Can they not be test/OAM packets?
Do we need the "user" keyword here?

> It SHOULD be possible to rely on user-plane traffic to achieve that
 > functionality.

Why?

> 2.2.12. Delay Measurement
> It SHOULD be possible to rely on user-plane traffic to achieve that
> functionality.

Why?

On 6/29/09 6:37 AM, "Loa Andersson" <[email-masked]> wrote:

All,

/Loa

--

Loa Andersson

---

From: Yuji Tochio <[email-masked]>
Date: Fri, 17 Jul 2009 11:54:58 +0900

Following are my comments...

* general
I am a little confused by the usage of function and
mechanism in this draft since functionality is added
(or modified).
Do the function and mechanism say as same meaning?
I ask for clarification

2.1.2. Independence
Currently this sub clause is saying two points that are
that between/of PW and LSP and that of C/M planes.

Consiering that this sub clause is rather long,
it could be better to create new sub title as 2.1.2.1(for PW & LSP
aspects) and 2.1,2.2 (for C/M-plane aspcts).

2,1.3
As many people pointed out, a little more clarification is required.
(Basically I support comments form Jia and Juergen)
For me it is not clear what the relationship of the cases last
paragraph and two "environments" above is.

Thus I am confused if "at least" is applicable to the second
"environments". Does it say that the protocol solution (s) must
cover for both two cases? If so, I ask for the clarification.

2.2
Just editorial...
"MPLS-TP should abide" -- abide sounds not proper/familiar to me.
Could it be modified to "MPLS-TP should be operated"

2.2.7 Lock reporting
I am not sure what external lock condition means, as Juergen indicated.
However, text should be simplied as following as editorial.

The MPLS-TP OAM toolset MUST provide functionality to enable an
Intermediate Point of a PW or LSP to report to its End Point an
external lock condition affecting that PW or LSP.

2.2.10 Client Failure Indication
The term of "client defect" should be clarified.
Does include the failure in MPLS-TP network?

The point is to clafify "fault condition detected at an End
Point". It requires the detection point of it (i.e. Inside of
MPLS-TP or outside of it (= client))

Thanks,
Yuji

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 17 Jul 2009 09:04:24 +0200

Hello Ben,

You wrote:

--8<---

> environments where IP routing & forwarding are present and environments

That is exactly what we agreed. So I see no need to change this.

> compatible equipment (IP support or not) at least on the two end points of

In transport networks these scenarios (where sections of a domain
path support more funcionality as other sections) can exist and in
general in these cases the interop is selcted/provisioned that
guarantees interworking.

This is in particular valid during transition periods where networks
are upgraded and also during reconfiguration for maintenance reasons.

> If my view above is shared, then the scope of OAM interoperability
 > is much reduced as availability of IP for use with OAM is consistent
 > within a domain and also for the End Points of any End to End OAM
 > flows.

I do *not* share your view

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

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 08:24:02 +0100

Hi Hubb...a question/observation...please see in-line: 

Huub wrote 17 July 2009 08:04
 
> I do *not* share your view

NH=> I am not clear which specific aspect you are disagreeing with Ben
here.  It can be easily shown that any networks that are not
top-of-stack (ie do not directly support external message/file/stream
applications) must, by obvious definition, be supporting a higher layer
network that may/may-not itself be top-of-stack...and so we recurse
upwards until we hit a true top-of-stack network (since this MUST always
be present in all cases, else all (lower) level networking serves no
purpose).

The key technical corollary of this observation is that it is not a
requirement to peer-interwork/interoperate (which is far more than just
DP OAM considerations) networks that are not top-of-stack....all cases
of MPLS, inc MPLS-TP, are not top-of-stack.

So whilst I would not want to stop those who think peer interworking
between technologies that are not top-of-stack is a 'good thing' (though
I would hope even those folks can see that attempting peer interworking
of technologies belonging to different network modes would be
significantly technically problematic per se and not a good idea at
all), it must not be a mandatory imposition on operators who can
figure-out this is unnecessary work/cost with potentially undesirable
commercial/regulatory consequences.

Would you not agree with this operator observation Huub?

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 17 Jul 2009 12:55:28 +0200

ITU-T requirement 23 in of section 8/Y.Sup4 has not been captured in this
OAM Requirements draft.
-------Requirement 23/Y.sup4-----------
23)	T-MPLS OAM should allow for a stateless layer network interworking
(also known as service interworking) between T-MPLS (based on [ITU-T
G.8110.1]) and an Ethernet (based on [ITU-T G.8010]) network.
---------------------------------------

Please add to the OAM requirements draft the requirement that MPLS-TP OAM
should allow for stateless layer network interworking (also known as service
or peer interworking) between MPLS-TP and Ethernet (based on G.8010)
networks. 

An example of such layer network interworking is when an Ethernet AC
carrying e.g. a TDM signal as per MEF8 is connected to a MPLS-TP network in
which a PW carries this TDM client signal as per RFC4553. The "MPLS and
Ethernet OAM Interworking" specifications will be much less complex when
MPLS_TP OAM is designed for stateless layer network interworking with
Ethernet.

Regards,
Maarten

> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; 
> Ross Callon; Adrian Farrel
> We chosen to start this last call already now and prolong it one week 
> since we have a a parallel wg last call on the network management 
> requirements (ending July 10).
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 17 Jul 2009 16:49:59 +0200

Hi,

I have a general comment to the OAM requirement draft. 

It is specified in the document that the protocol solutions MUST be
applicable to "point-to-point bidirectional PWs, point-to-point
bidirectional LSPs, and point-to-point bidirectional Sections and SHOULD
additionaly <TYPO> be applicable to unidirectional point-to-point and
point-to-multipoint LSPs". However, I think specific requirements for
p2mp are missing.

For example, should we have a return path in order support different
functions (such as trace route, CV, etc.)? is it required that the
return paths are co-routed?

How can we implement two ways delay measurement? This is true also for
uni-directional p2p transport paths. 

What I miss is actually some information for each function, for which
transport entity it is required (e.g. unidirectional p2p, p2mp,
co-routed bidirectional p2p, etc.), and more requirements specifically
for p2mp as indicated above.

Best regards,

Nurit

--------------------------------------------------------

All,

/Loa

--

Loa Andersson

                                              [email-masked]

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 17 Jul 2009 17:18:21 +0200

Hi,

One more comment from my side.

In section 2.2.8, it required to be able for an intermediate node to
report its MEPs of a fault or defect condition affecting that PW or LSP.

I think it can be useful to specify which faults/defects should be
reported, and to request for the capability to configure the
intermediate nodes which alarms should be reported to the MEPs (e.g.
server failure, cross-connect issue, etc.). 

As most of the failures of LSPs for example result from a server
failure, it may be useful to report only other faults and let the MEP
assume a fault of a LSP results from a failure of the server somewhere
along the path, unless another fault/defect is reported to it by an
intermediate node. By this we can reduce significantly the number of
messages that are needed to be generated. 

We can for example request a node that has cross-connect problem which
causes a black-hole to send a report to the MEP. A MEP that defects
missconnectivity (LSP which erroneously terminates on it) will report
the missconncetivity to the OSS/NMS. Do we expect to more failure that
can affect the LSP except of these and a failure of a server? 

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Friday, July 17, 2009 5:50 PM
To: Loa Andersson; [email-masked]; RossCallon; Adrian Farrel
Subject: Re: [mpls-tp] WK Last Call
ondraft-ietf-mpls-tp-oam-requirements-02.txt

Hi,

It is specified in the document that the protocol solutions MUST be
applicable to "point-to-point bidirectional PWs, point-to-point
bidirectional LSPs, and point-to-point h Sections and SHOULD additionaly
<TYPO> be applicable to unidirectional point-to-point and
point-to-multipoint LSPs". However, I think specific requirements for
p2mp are missing.

Best regards,

Nurit

All,

/Loa

--

Loa Andersson

                                              [email-masked]

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:14:32 +0200

Hi Jiang,

thanks for your comments.
please see in-line.

regards,
-m

Jiang Yuan-long a écrit :
> Hi all,
> In draft-ietf-mpls-tp-oam-requirements-02.txt,
> 1. In section 2.1.3, two requirements are presented, the first says:
>  "...IP routing and forwarding capabilities are inherently present in
>  the forwarding  plane..."
> the second says:
>  "...IP routing and forwarding capabilities may not necessarily be
>  present in the user plane. In this case, it MUST be possible to
>  operate the OAM functions without relying on IP routing and
>  forwarding capabilities..."
> AFAIS, user plane is only used for user traffic forwarding, so no IP 
> capabilities in user
> plane does not necessarily preclude OAM (which is logically different 
> from user traffic) with IP.
> Therefore, "user plane" should be replaced with the same "forwarding 
> plane", IMO.

seeing other comments about that point, I'll rework.
I may use "data plane".
> 
> 2. In section 2.1.4, it says:
> "...It is also REQUIRED that
>   the two first requirements of Section 2.1.3 still hold..."
> Maybe "first" should be deleted?

no, because there are three requirements.
> 
>   Thanks
> Jiang Yuanlong
> 
> 
> ----- Original Message ----- From: "Loa Andersson" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; "Ross Callon" <[email-masked]>; "Adrian Farrel" 
> <[email-masked]>

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:15:29 +0200

Ben,

thanks for your review.
Please see in-line.

regards,
-m

> Do we want to use the same or similar text in all MPLS-TP requirements

yes, will do so.
> and also for the End Points of any End to End OAM flows.

This was indeed the objective of the paragraph.
Knowing that you have the good reading, do you think it is necessary
to rework the text?
By staying relatively generic we have a certain level of guaranty
not to miss a something.
Let me know.
> 3) Introduction (Page 3) 5th bullet s/meet service/meeting service/

ok
> 4) Section 2.2.4, there are two occurrences where you need to

ok
> they mean the same thing we may want to be consistent and just chose one or

I feel that sometime SHALL better fits in a given sentence that MUST
but that is really personal.

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:19:28 +0200

Dear Jia,

regards,
-m

> Is it bidirectional associated or bidirectional co-routed? It is better to state explicitly here and in the latter general requirement part since some OAM functions may have dependency on the type…

It is both. I will clarify.
> Besides, it is also beneficial to claim the limitation or additional requirements for OAM functions applied in unidirectional transport path.

I take this comment as going in the same direction as those
of Annamaria and Rolf and others.
> 1) From the title of this section "Addressing, Routing and Forwarding", I'm expecting to read the basic forwarding requirements for MPLS-TP OAM, e.g. how to forward a MPLS-TP OAM packet (based on t…

This section details the requirements considering the possible
environments in which OAM could be deployed and covers, as the title
says, requirements pertaining to addressing, routing and forwarding.
Therefore I am not sure how could I clarify this.
> 2) The first paragraph is talking about a "MUST" requirement in IP/MPLS environment. I'm not sure why it is included in the MPLS-TP OAM requirement? What's the relationship between IP/MPLS environm…

we can not preclude the OAM functionality that will arise from this
document to be used in MPLS environments where IP capabilities are
present and in that context we can not preclude the usage of these
capabilities.
It is not however up to that document to specify what is mpls-tp with
regards to ip/mpls
> Since we do have scenarios in MPLS-TP environment where IP routing and forwarding is not supported as described, it is therefore a "MUST" in MPLS-TP OAM to develop tool-set without depending on IP…

we have to make a distinction between oam functionality and the
data-plane capabilities on which it may rely to operate.
The draft puts forward various contexts ("IP with" & "IP less") that
stand as rationales for the requirements (i.e., MUST be possible to
operate with and without relying on IP). The draft does not put
requirement on which forwarding principle to use in which context.

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:24:07 +0200

Italo,

regards,
-m

> I think it would be useful to clarify this point in the scope of the

Is the suggestion similar to Ben's (i.e., re-use text from the normative
language section of mpls-tp-requirements)?
> different packet sizes in order to verify also MTU problems.

this was indeed in the previous rev but got lost (due to the table
disappearance)

ok
> c/a client defect of/a client defect or/

ok. Yaacov caught this one as well.
> I would propose to call it "Packet Delay Measurement"

ok will clarify these two.

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:26:16 +0200

Nitin,

regards,
-m

> The last sentence above is very general and vague. The "SHOULD" statement should be removed.

It is indeed general this is why SHOULD was used.
Do you feel that this will be impossible to meet?
> it of a failure in someone else's domain.

Would "aware" be better than "informed"?
> Will still be allowed to go through for locked LSP/PW segments.

I'll copy paste the answer I gave to Yaacov who raised the same question:
I understand your point, yet I fear that in this case we would start
dictating systems internal capabilities, which is outside the scope
of this document.
Nevertheless I would tend to say that client traffic is blocked.
> to report regarding the lock condition. Maybe I missed something obvious.

No, you did not miss something obvious.
This text follows discussions on lock & alarm.
It was raised at that time that the draft should not require
cross-layer oam "notifications" (i.e. from the end point of
a tunnel towards the end-points of tunneled lsps).
It would be up to a functional intermediate point of an lsp (collocated
with the end point of the tunnel) to report to its end points the condition.

> Then how is it supposed to inform the LSP end-point pro-actively ?

Please see the answer above. It should also clarify this point
> Is that the case that is being asked for?

the loss of CC would enable to detect a problem.
the alarm notification is a functionality that would enable to perform
alarm summarization/correlation. A device that stops receiving CC
and also receives alarm notification would be in a position to
understand that an event, which is indirectly affecting
the e.g., lsp for which cc has stopped working, has occurred.
> If so, then it means we need to define a OAM mapping scheme for all client types.

could you elaborate what you mean by mapping? thx.
> Do we need the "user" keyword here?

No, indeed. The use of "user" in the Note is incorrect as we allow
to either use user packets or OAM packets to perform that functionality.
>> It SHOULD be possible to rely on user-plane traffic to achieve that

Because we do not want to impose to only use OAM.
To obtain a certain level of confidence with regards to the obtained
results a very important number of packets may need to be sent
to appropriately catch "rare" events and as such user packets natively
satisfy that objective.
>> It SHOULD be possible to rely on user-plane traffic to achieve that

Cut and paste error. this should not be there. thx.

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:27:43 +0200

Hi Huub,

I do not think Ben is asking for change but for clarification.
I as read it, you agree with Ben's reading but then state
you do not agree with his view. I must have missed something.
Thanks.

regards,
-m

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:27:11 +0200

Dear Yuji,

regards,
martin

> Do the function and mechanism say as same meaning?

In my view, "function" specifically refers that what is done
while "mechanism" is more general and refers to what is needed
for the OAM to work. But this is in no way an absolute definition.
> aspects) and 2.1,2.2 (for C/M-plane aspcts).

is the length of a sub-section an issue?
> paragraph and two "environments" above is.

please see the answers given to the similar questions.
> cover for both two cases? If so, I ask for the clarification.

The last paragraph of section 2.1.3 applies independently of the
environment.
> Could it be modified to "MPLS-TP should be operated"

Please read it as "the requirements the oam should agree to"
(but I may have a bad understanding of the meaning of "to abide by")
> However, text should be simplied as following as editorial.

external means that it is not that LSP/PW which is locked
> Does include the failure in MPLS-TP network?

Here client refers to "client to the mpls-tp network"
> MPLS-TP or outside of it (= client))

 From the context I felt that it was quite straight forward
that the failure is "outside" of the network.

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:28:24 +0200

Maarten,

do you mean that an MPLS-TP OAM process should be capable of receiving
an Ethernet OAM message and translate it into an MPLS-TP OAM message
which is then sent into the MPLS-TP OAM network?

regards,
-m

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:28:50 +0200

Dear Nurit,

you are not the first one to raise such comment.
As I said earlier the risk is to fall into restrictive solutions specs.
But we may have to take a bit that risk to provide more details
to the draft.
Also I fear the draft will loose in readability if for each
functionality we have to clarify all the degrees of freedom
(unidir/bidir, e2e/e2i, p2p/p2mp, pw/lsp/sections, proactive/on-demand,
...).
We'll see what can be done.

regards,
martin

Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
> point-to-multipoint LSPs". */_However_/*, I think specific requirements 
> for p2mp are missing.
> 
> For example, should we have */_a return path _/*in order support 
> different functions (such as trace route, CV, etc.)? is it required that 
> the return paths are co-routed?
> 
> ------------------------------------------------------------------------
>

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:29:17 +0200

Dear Nurit,

thanks.
please see in-line.
regards,
-m

Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
> I think it can be useful to specify */_which faults/defects should be 
> reported_/*, and */_to request for the capability to configure the 
> intermediate nodes which alarms should be reported to the MEPs_/* (e.g. 

It may indeed be valuable to clarify in which context such reporting
should happen.
I am however reluctant to talk about the capability to configure such
functionality.
We have a general requirement that is applicable to all functionalities
and which says
    OAM functions MUST operate and be configurable even in the absence of
    a control plane.  Conversely, it SHOULD be possible to enable/disable
    the capability to operate OAM functions as part of connectivity
    management
I believe this is sufficient and we do not need to get into the details,
as, at that stage, we could not really say what should be configured.

> failure, it may be useful to report */_only_/* other faults and let the 
> MEP assume a fault of a LSP results from a failure of the server 
> somewhere along the path, */_unless_/* another fault/defect is reported 
> to it by an intermediate node. By this we can reduce significantly the 
> number of messages that are needed to be generated.
> 
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext Sprecher, Nurit (NSN - IL/Hod HaSharon)
> *Sent:* Friday, July 17, 2009 5:50 PM
> *To:* Loa Andersson; [email-masked]; RossCallon; Adrian Farrel
> *Subject:* Re: [mpls-tp] WK Last Call

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 17 Jul 2009 22:13:32 +0200

Bonsoir Martin,

> you do not agree with his view. I must have missed something.

The way I read Ben's comments is that he wants to restrict a
domain to have either all equipment supporting IP or *not*
supporting IP.

See furhter in-line [hvh]

>> That is exactly what we agreed. So I see no need to change this.

[hvh] I read this such that it is required that in an environment
that contains equipment *not* supporting IP and supporting IP, it
should be possible to use MPLS-TP OAM that does *not* rely on IP.
Or, in other words, the IP supporting equipment has to able to
support the non-IP MPLS-TP OAM. Particularly when the end nodes
use MPLS-TP IP-less OAM.

>>> Is it possible to scope this interoperability requirement so that
>>> the consequences of it are clearer, for example I can see an end
>>> to end path may traverse different "domains" where some domains
 >>> use IP capability for OAM and some do not.
 >>> I think it unlikely to have a mix of such equipment within a
>>> single domain.

[hvh] I do not agree with this last statement.

>>> Furthermore I would expect end to end OAM to have compatible
 >>> equipment (IP support or not) at least on the two end points
 >>> of the path.

[hvh] if the IP supporting equipment also supports IP-less OAM
there is no need to expect this.

>> I do *not* share your view.

[hvh] I do not share the conclusion that the scope is reduced.
as I tried to explain above.

Best regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 23:40:46 +0200

Hi,

I have some additional LC comments on this draft.
(line numbers included as generated by the nits mode)

1) General

It is mentioned in the scope that a service (and related PW/LSP) may
span over several segments / domains.
However I'd like to see a more strong and clear definition in the
document, that MPLS-TP OAM protocols MUST support end-to-end operation
over several segments and domains.

2)  	   2.1.2.  Independence

213	   The protocol solutions SHOULD be independent of the
underlying
214	   tunnelling or point-to-point technology or transmission
media. 

No need to explicitly mention "point-to-point" here -> could be removed.

2)       2.1.3.  Addressing, Routing and Forwarding

266	   In cases where OAM messages need to incorporate
identification
267	   information (e.g., source and/or destination nodes), the
protocol
268	   solution(s) MUST at least support an IP addressing structure
and MUST
269	   also be extensible to support additional identification
schemes.

According to the requirement to operate MPLS-TP OAM without relying on
the presence of IP routing and forwarding capabilities,
my proposal is (supporting a comment on the same matter made by Jia and
others earlier on this list) to change the priority and text as follows:

In cases where OAM messages need to incorporate identification
information (e.g., source and/or destination nodes), the protocol
solution(s) MUST support appropiate identification schemes that do not
rely on IP routing and forwarding capabilities. In case where IP routing
and forwarding capabilities are inherently present, IP addressing
structures MAY be used.

Best regards,
Manuel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Loa Andersson
Sent: Monday, June 29, 2009 3:38 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ross
Callon; Adrian Farrel
Subject: [PWE3] WK Last Call on
draft-ietf-mpls-tp-oam-requirements-02.txt

All,

/Loa

-- 

Loa Andersson

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

---

From: <[email-masked]>
Date: Sat, 18 Jul 2009 08:20:36 +0100

Martin,

> no, because there are three requirements.

In which case the correct English is "the first two requirements of
Section..."

Ben

---

From: <[email-masked]>
Date: Sat, 18 Jul 2009 08:51:18 +0100

Huub,

> domain to have either all equipment supporting IP or *not*

That's exactly what I am proposing, noting that a single operator network
may be composed of one or more domains.

Otherwise, it means every node in the network must be capable of translating
between IP-based and IP-less OAM. It means every node must have awareness of
which of its neighbours support IP-based OAM and which support IP-less OAM.
That's a lot of complexity/knowledge/configuration to introduce.

Typically we try to restrict complexity to the edge of a domain.

It would be interesting to hear a specific example of mixed capabilities
similar to IP-less and IP-based OAM in a single domain in a transport
network as I've never come across a case in the networks I've been involved
with of such mixed capabilities leading to interoperability being performed
by nodes that are not at the edge of a domain.
 
Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sat, 18 Jul 2009 20:43:06 +0200

Hi,
I am doubt if this is in the scope of MPLS_TP. 
This may be relevant in the scope of L2VPN if required. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Martin Vigoureux
Sent: Friday, July 17, 2009 9:28 PM
To: Maarten Vissers
Cc: 'MPLS-TP ad hoc'; [email-masked]
Subject: Re: [mpls-tp] WK Last Callondraft-ietf-mpls-tp-oam-requirements-02.txt

Maarten,

regards,
-m

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sat, 18 Jul 2009 20:48:21 +0200

Martin,

">> 2.2.6. Lock Instruct

of this document.

Nevertheless I would tend to say that client traffic is blocked."

We must understand what should be the network behavior in case of "lock", in terms of data traffic transmission and well as control packets (not only OAM). 

Best regards,

Nurit 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Martin Vigoureux
Sent: Friday, July 17, 2009 9:26 PM
To: Nitin Bahadur
Cc: [email-masked]
Subject: Re: [mpls-tp] WK Last Call ondraft-ietf-mpls-tp-oam-requirements-02.txt

Nitin,

Please see in-line.

regards,

-m

of this document.

satisfy that objective.

 

mpls-tp mailing list

[email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 20 Jul 2009 09:03:05 +0200

Hi Ben,

You wrote:

> between IP-based and IP-less OAM.

It is not necessary to do a translation, there are more options:
-- it would also be possible that nodes support both non-IP MPLS-TP OAM
    and IP MPLS OAM.
-- it would also be possible that non-IP MPLS-TP OAM is passed through
    IP nodes with being affected (which means that no MIPs can exist in
    that part of the network).
-- the traffic with non-IP MPLS-TP OAM is treated as a client signal
    and transported in a tunnel through the IP nodes.

> It means every node must have awareness of

This is not required, see above.

> That's a lot of complexity/knowledge/configuration to introduce.

No complexity introduction in the three options above.

> Typically we try to restrict complexity to the edge of a domain.

I will not object to that.

Cheers, Huub.

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 20 Jul 2009 09:10:38 +0200

Martin,

Yes that is what I mean in one direction. In the other direction the reverse
process (receive an MPLS-TP PW OAM message and translate it into an Ethernet
OAM message) is required.

There are two service layers in a packet transport network: 1) Ethernet VLAN
(EVC) and 2) Multi-Segment Pseudowire (PW). At the intersection of both
service layers the p2p or p2mp EVC and p2p or p2mp PW peer and the Ethernet
OAM and MPLS-TP PW OAM peer. An NNI port in a MPLS-TP node with PW as
service layer for p2p and p2mp services may be connected to a NNI node in a
PTN node with EVC as service layer for all services, including p2p and p2mp
services. The NNI port in the MPLS-TP node will receive a p2p or p2mp EVC
with Ethernet OAM and has to forward this signal as a MS-PW with MPLS-TP
OAM, and vice versa. This NNI port has to interwork the Ethernet and MPLS-TP
PW OAM and it has been a requirement for many years in ITU-T that this
interworking should be stateless.

Regards,
Maarten

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]] 
Sent: vrijdag 17 juli 2009 20:28
To: Maarten Vissers
Cc: [email-masked]; 'MPLS-TP ad hoc'
Subject: Re: [mpls-tp] WK Last Call

Maarten,

do you mean that an MPLS-TP OAM process should be capable of receiving an
Ethernet OAM message and translate it into an MPLS-TP OAM message which is
then sent into the MPLS-TP OAM network?

regards,
-m

Maarten Vissers a écrit :
> ITU-T requirement 23 in of section 8/Y.Sup4 has not been captured in 
> this OAM Requirements draft.
> Please add to the OAM requirements draft the requirement that MPLS-TP 
> OAM should allow for stateless layer network interworking (also known 
> as service or peer interworking) between MPLS-TP and Ethernet (based 
> on G.8010) networks.
> 
> carrying e.g. a TDM signal as per MEF8 is connected to a MPLS-TP 
> network in which a PW carries this TDM client signal as per RFC4553. 
> The "MPLS and Ethernet OAM Interworking" specifications will be much 
> less complex when MPLS_TP OAM is designed for stateless layer network 
> interworking with Ethernet.
> 
> Regards,
> Maarten
> 
>

---

From: <[email-masked]>
Date: Mon, 20 Jul 2009 09:34:51 +0100

Hi Hubb...I have a concern here....

Huub van Helvoort wrote 20 July 2009 08:03
 
> I will not object to that.

Whilst it is possible to have many different types of OAM running in a
single layer network (any mode/technology, not simply MPLS-TP) it's not
a good idea.  The simple reason is that if there is misconnectivity
between LSPs that are running different OAM then this creates a problem
of how to deal with it.  So if there are N types of OAM say then each
LSP sink point (also see note) needs to be capable to interpreting each
of the N types of OAM and handling them correctly (note - I am ignoring
any further complexities due to nested TCM MEPs/MIPs).  And one would
assume this also has a $ cost too.

regards, Neil

---

From: Jiang Yuan-long <[email-masked]>
Date: Mon, 20 Jul 2009 17:36:25 +0800

Hi Martin,
Also in Section 2.1.3, it says:
"  In cases where OAM messages need to incorporate identification
   information (e.g., source and/or destination nodes), the protocol
   solution(s) MUST at least support an IP addressing structure and MUST
   also be extensible to support additional identification schemes."
Do you mean that there are other cases where no identification info is 
needed
in the OAM msgs, and no any requirement on them?

Thanks
Jiang Yuanlong

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 21 Jul 2009 12:58:54 +0200

Hi Neal,

You replied:

>>     IP nodes without being affected (which means that no MIPs 
>> can exist in
> a good idea. 

[hvh] in the first of the three options I wrote "support both" which
does not mean that it is mandatory to use them both at the same time
in the same layer.

> The simple reason is that if there is misconnectivity
> of how to deal with it. 

[hvh] there is always a possiblity that this happens, so your design
should be able to handle this. This has been discussed extensively
already,

> So if there are N types of OAM say then each
> of the N types of OAM and handling them correctly 

[hvh] No, the conclusion was that known OAM (which is only one)
shall be acted upon, all others are either ignored and forwarded
if possible, or dropped if that is not possible.

>(note - I am ignoring
> any further complexities due to nested TCM MEPs/MIPs). 

[hvh] for the last few month you are the only one mentioning
this three letter acronym.

Regards, Huub.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Jul 2009 15:00:22 +0200

All,

Nurit is right - this is out of scope for mpls-tp.

For any IETF working group to do this type of work, it will take a
rechartering of that working group.

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: [email-masked]
Date: Thu, 23 Jul 2009 09:55:52 +0800

hi.all,
according to  your discuss, I can't compeletely understand what you said. 
which layer may the interworking of OAM be used for? transport layer or 
service layer?
maybe we have a clear definition ? or else, we will not have a common 
agreement.

best regards
liu

Loa Andersson <[email-masked]> 
发件人:  [email-masked]
2009-07-22 21:00

收件人
Maarten Vissers <[email-masked]>
抄送
'MPLS-TP ad hoc' <[email-masked]>, [email-masked]
主题
Re: [mpls-tp] WK Last Call ondraft-ietf-mpls-tp-oam-requirements-02.txt

All,

/Loa

> do you mean that an MPLS-TP OAM process should be capable of receiving 
an

-- 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: <[email-masked]>
Date: Thu, 23 Jul 2009 08:55:55 +0100

It's not that simple Liu.  Please forget the arbitrary and artificial names such as 'transport layer' or 'service layer' as they are not very meaningful.  The real situation is like this:
 
-    From considerations of how a resource (be it time/space/freq) is partitioned and labelled (to distinguish clients using those resource partitions) we get 3 different network modes: cl-ps, co-ps and co-cs.  (The reasons for this are explained in G.800).  All technologies map to one of these modes.  The 'goodness' of particular technology is then determined by how well its DP, CP and MP components are specified......OAM is only one DP component.....and it should also be noted that the OAM required for each of the 3 network modes is not identically the same.  So just considering the interworking of OAM between different technologies is quite naive at best.  Further, the 3 network modes are different and each offers something the others can't.  For a full service operator all 3 modes are equally important.  This is why IETF supplements IP (cl-ps) with MPLS (co-ps) and GMPLS (co-cs).....this is not chance/coincidence, its stems directly from the physics at work here.  Put another more simple way: one mode/technology cannot do-it-all.
 
-    If we wish to peer interwork 2 different network technologies then we have to consider several things, for example:
 
    o is at least one of the technologies not top-of-stack?  (Aside=> A top-of-stack network directly supports external (to the network) message/file/stream applications).  If the answer is yes, then is quite trivial to show that peer-interworking has no technical benefit...it just creates problems and cost.  We are far better off simply terminating the 2 non top-of-stack server networks and transparently passing across (all 3 planes of) the common higher layer client network (which MUST be present by definition of what top-of-stack means).
 
  o do the 2 technologies belong to same network mode?  If the answer is no, then irrespective of the point above (which is the ultimate decision factor in all cases) there is going to be a significant mismatch of DP, CP and MP components which may have no good interworking solution anyway.
 
The above is a short technical explanation of why Loa is correct in saying that Ethernet and MPLS(-TP) peer interworking is not within charter scope.   And BTW note that both Ethernet and MPLS(-TP) are not top-of-stack layer networks anyway.....so interworking them as peers is technically unnecessary even if it was in scope of the WG. 
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 23 July 2009 02:56
	To: Loa Andersson; Maarten Vissers
	Cc: [email-masked]
	Subject: Re: [mpls-tp] WK Last Callondraft-ietf-mpls-tp-oam-requirements-02.txt

	hi.all, 
	according to  your discuss, I can't compeletely understand what you said.  which layer may the interworking of OAM be used for? transport layer or service layer? 
	maybe we have a clear definition ? or else, we will not have a common agreement. 
	
	best regards 
	liu

2009-07-22 21:00 

收件人

	All,

	
	/Loa

	--

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 23 Jul 2009 17:46:26 +0200

Liu,
 
I have attached a couple of slides in which I illustrate two layer stacks
which you find in the packet transport network.
The first layer stack deploy the EVC as service layer (slide 1), the second
layer stack deploys the PW and EVC as service layers (slide 2).
As customers don't care which service layer technologies are being deployed
by the different parts of the network, it will be necessary to interconnect
both packet transport network alternatives at some time in future. This is
illustrated in slide 3. For the Line type services (e.g. E-LINE, TDM, ATM,
FR, ..) it will be required to interwork the EVC carrying those services in
one part of the network with the PW carrying those same services in the
other part of the network.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 23 juli 2009 3:56
To: Loa Andersson; Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] WK Last Call
ondraft-ietf-mpls-tp-oam-requirements-02.txt

hi.all, 

best regards 
liu

2009-07-22 21:00 

收件人

抄送

主题
Re: [mpls-tp] WK Last Call
ondraft-ietf-mpls-tp-oam-requirements-02.txt

All,

/Loa

-- 

ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 23 Jul 2009 17:56:58 +0200

Loa,

This is a long standing requirement from the initial days of T-MPLS, as it
was identified that 
1) we have Ethernet VLAN (EVC) and PW being used today in the different
networks as service layer technologies for LINE type services and 
2) we have the requirement that a packet transport network must be capable
to provide services between any two (or more) points in the world.

Thus sooner or later we will be forced to support a LINE type service that
has one endpoint in an EVC service layer domain and the other endpoint in a
PW/EVC service layer domain. Good engineering practice is that such
important interconnection capability is taken into consideration from the
first day of the development of e.g. OAM. As the Ethernet OAM is done and
the PW OAM is under development, it is the PW OAM choices that can make such
interconnection simple or complex. The requirement is as such an important
requirement for the choice of PW OAM PDU formats, and is thus fully in scope
of MPLS-TP OAM in my opinion.

Regards,
Maarten

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: woensdag 22 juli 2009 15:00
To: Maarten Vissers
Cc: 'Martin Vigoureux'; [email-masked]; 'MPLS-TP ad hoc'
Subject: Re: [mpls-tp] WK Last Call

All,

/Loa

Maarten Vissers wrote:
> Martin,
> 
> Yes that is what I mean in one direction. In the other direction the 
> reverse process (receive an MPLS-TP PW OAM message and translate it 
> into an Ethernet OAM message) is required.
> 
> (EVC) and 2) Multi-Segment Pseudowire (PW). At the intersection of 
> both service layers the p2p or p2mp EVC and p2p or p2mp PW peer and 
> the Ethernet OAM and MPLS-TP PW OAM peer. An NNI port in a MPLS-TP 
> node with PW as service layer for p2p and p2mp services may be 
> connected to a NNI node in a PTN node with EVC as service layer for 
> all services, including p2p and p2mp services. The NNI port in the 
> MPLS-TP node will receive a p2p or p2mp EVC with Ethernet OAM and has 
> to forward this signal as a MS-PW with MPLS-TP OAM, and vice versa. 
> This NNI port has to interwork the Ethernet and MPLS-TP PW OAM and it 
> has been a requirement for many years in ITU-T that this interworking
should be stateless.
>>> We chosen to start this last call already now and prolong it one 
>>> week since we have a a parallel wg last call on the network 

--

---

From: <[email-masked]>
Date: Thu, 23 Jul 2009 18:24:32 +0200

Hi Maarten,

When I get you right and things are working as you described, will I be transparent in the way a transport-layer like MPLS TP should behave for a client layer in the end?

Regards
Markus

Deutsche Telekom Netzproduktion GmbH 
Zentrum Technik Einführung
Dipl. Ing. Dipl. Wirtsch. Ing. 
Markus Lautenschlager 
TE241-11 
Hansastr. 35, 90441 Nürnberg 
+49 911 150 4233 (Tel.) 
+49 951 91733648 (Fax) 
+49 160 90719250 (Mobil) 
E-Mail: [email-masked]
http://www.telekom.com 

Deutsche Telekom Netzproduktion GmbH 
Aufsichtsrat: Timotheus Höttges (Vorsitzender) 
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren 
Handelsregister: Amtsgericht Bonn HRB 14190 
Sitz der Gesellschaft: Bonn 
USt-IdNr.: DE 814645262

Erleben, was verbindet.

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maarten Vissers
Gesendet: Donnerstag, 23. Juli 2009 17:57
An: 'Loa Andersson'
Cc: 'MPLS-TP ad hoc'; [email-masked]
Betreff: Re: [mpls-tp] WK Last Callondraft-ietf-mpls-tp-oam-requirements-02.txt

Loa,

Regards,
Maarten

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: woensdag 22 juli 2009 15:00
To: Maarten Vissers
Cc: 'Martin Vigoureux'; [email-masked]; 'MPLS-TP ad hoc'
Subject: Re: [mpls-tp] WK Last Call

All,

/Loa

should be stateless.

--

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 23 Jul 2009 21:30:16 +0200

Markus,

Yes in both PTN options you will be transparently transferring any of the
client layer signals as those clients expect. Both PTN options are in
operation today and provide their clients the required transparency. 

When you interconnect an EVC (with client X) in an option 1 network with an
EVC (with same client X) in an option 2 network, then client X is
transparently transferred between its UNI ports as you would expect as both
options use the same service technology (EVC) to carry X.

When you interconnect an EVC (with client X) in an option 1 network with a
PW (with same client X) in an option 2 network, then client X is
transparently transferred between its UNI ports as both options use the same
client X encapsulation method (PWE3 based) to carry X. In addition the
hybrid EVC-PW connection will be monitored between EVC endpoint and PW
endpoint by the Ethernet OAM in the EVC part of the connection, the
translation of this OAM into PW OAM in the IWF and then the PW OAM in the PW
part of the connection. The required stateless interworking of PW OAM with
Ethernet OAM guarantees that the translation of Ethernet OAM into PW OAM
(and vice versa) will be a very trivial translation, which does not require
configuration of the IWF.

Regards,
Maarten

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: donderdag 23 juli 2009 18:25
To: [email-masked]
Cc: [email-masked]
Subject: AW: [mpls-tp] WK Last
Callondraft-ietf-mpls-tp-oam-requirements-02.txt

Hi Maarten,

When I get you right and things are working as you described, will I be
transparent in the way a transport-layer like MPLS TP should behave for a
client layer in the end?

Regards
Markus

E-Mail: [email-masked] http://www.telekom.com 

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Timotheus Höttges (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis,
Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262

Erleben, was verbindet.

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag
von Maarten Vissers
Gesendet: Donnerstag, 23. Juli 2009 17:57
An: 'Loa Andersson'
Cc: 'MPLS-TP ad hoc'; [email-masked]
Betreff: Re: [mpls-tp] WK Last
Callondraft-ietf-mpls-tp-oam-requirements-02.txt

Loa,

Regards,
Maarten

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: woensdag 22 juli 2009 15:00
To: Maarten Vissers
Cc: 'Martin Vigoureux'; [email-masked]; 'MPLS-TP ad hoc'
Subject: Re: [mpls-tp] WK Last Call

All,

/Loa

should be stateless.

--

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 23 Jul 2009 18:21:48 -0700

Hi Martin,

  Thanks for clarifying a bunch of things. Some more comments inline.

> Do you feel that this will be impossible to meet?

I don't think it will be impossible to meet. But given that there is nothing specified, it becomes hard to come up with a solution that that meets the requirements. I can come up with *a solution* and maintain that my solution meets the requirements but others might disagree with me because their definition of corrective action might be different. 

> Would "aware" be better than "informed"?

Yes. That would be good.

> Nevertheless I would tend to say that client traffic is blocked.

Can we clarify that the lock instruct MUST apply to client traffic. That would keep the requirement crisp.

> with the end point of the tunnel) to report to its end points the

Ok. Then can you add that clarification someplace in the document.

> Please see the answer above. It should also clarify this point

Yes, it does now.

> the e.g., lsp for which cc has stopped working, has occurred.

But if CC has failed, then most likely the end to end path has failed and so an end-point cannot report the alarm to the other end-point. The only possibility is for a transit node to notify the end-point of the condition.
I presume that is the intention. In which case, the alarm summarization/correlation should be not mandatory (because the failure got detected by CC). This functionality should be optional IMO.

> could you elaborate what you mean by mapping? thx.

By mapping I meant that we translate a fault in MPLS-TP LSP/PW into an appropriate fault code for the client OAM. So for example, let's assume you are running Ethernet as a client of MPLS-OAM and assume no Ethernet-oam alarm suppression is turned off. So now when mpls-oam detects a fault on the LSP, does the end-point need to map the lsp fault into a Ethernet fault?

What is the expected behavior as per this requirement?

> to appropriately catch "rare" events and as such user packets natively

This might be true in Ethernet world where the Ethernet OAM packets do not resemble the user packets. But in MPLS, the MPLS label stack (on which the packet is switched) is the same for OAM as well as user packets. So I don't see a specific need to inject user packets natively. If you feel otherwise, please specify a case or two.

Thanks
Nitin

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 24 Jul 2009 07:46:29 +0200

Liu,
 
You seem to misunderstand the issue. Solution 1 is in the field today and is
the PTN architecture used by a number of network operators (e.g. in the
Netherlands). As solution 1 is a less complex solution to manage then
solution 2 and as solution 1 supports the same customer services as solution
2, there is no rationale for those operators to change their existing
solution 1 PTN architecture into a solution 2 PTN architecture. In the world
wide PTN we will thus have to make sure that solution 1 and solution 2 PTN
domains interwork. Note that equipment capable to support solution 2 PTN can
be operated in solution 1 PTN mode by simply disabling the PW functionality.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 24 juli 2009 4:13
To: Maarten Vissers
Cc: 'Loa Andersson'; [email-masked]
Subject: RE: [mpls-tp] WK Last Call
ondraft-ietf-mpls-tp-oam-requirements-02.txt

maaten, 
thank you for your explaining. I reviewed your slides. IMO. for your option
solution 1, I think it is unnecessary to encapsulate all kinds of services
by the way of EVC. 
option solution 2 maybe be used in the future packet transport networks
under a few special conditions 

this is my personal opinions. 

best regards 
liu  

2009-07-23 23:46 

收件人
[email-masked], 'Loa Andersson' <[email-masked]> 

抄送
[email-masked] 

主题
RE: [mpls-tp] WK Last Call ondraft-ietf-mpls-tp-oam-requirements-02.txt

Liu, 

Regards, 
Maarten 

  _____  

hi.all, 

best regards 
liu 

2009-07-22 21:00 

收件人

抄送

主题

All,

/Loa

> Yes that is what I mean in one direction. In the other direction the
reverse

-- 

[附件 "ptn-service-layers-00.pdf" 被 刘国满180323/user/zte_ltd 删除]

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 24 Jul 2009 09:49:49 +0200

Adrian,

See inline... 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: donderdag 23 juli 2009 23:46
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] WK
LastCallondraft-ietf-mpls-tp-oam-requirements-02.txt

Maarten,

I believe you may have misunderstood Markus's questions.

Anyway, I have two questions.

1. Why do you assume that all technologies that build packet transport
networks must provide the same services in the same way and are not able to
behave differently? 

[mv] If you look at the layer stacks for the two PTN options, then you will
notice that the same services are supported in non-equal ways in option 1
and option 2; e.g. an E-Line service in option 1 is supported via a p2p EVC
and in option 2 via a p2p PW, an E-LAN service in option 1 is supported via
a mp2mp EVC and in option 2 via a mp2mp EVC plus a set of PWs.

[mv] The externally (i.e. customer) observed behaviour must however be
identical for the two options. I.e. the customer must not have to care what
service layer technology or technologies an operator deploys.

[mv] The network operator observed behaviour with respect to faults and
performance of transport entities should be technology independent. As such
the fault management and performance monitoring of transport entities in
different technologies should have similar behaviour. This implies that OAM
for different technologies must have similar capabilities. 

[mv] When two technologies are developed in parallel to support the same
applications, then sooner or later there is a requriement to interoperate
between both technologies. It is thus good engineering practice to take this
into account when developing the OAM for the second technology (in this case
MPLS-TP OAM).

This is a fundamental question. It does not detract from your goal of
providing a uniform packet transport network, but it suggests that your goal
should be met by a (possibly) thin layer than runs over all packet
technologies to unify them at the same functional level. It is in that layer
that you would run e2e PN OAM services. This frees the network technologies
to develop independently and leverage the behaviours of their own
technologies.

[mv] When you look carefully at the functionality required in your suggested
"thin" (service) layer and would compare this with the functionality
required in the tunnel/path layer, then you will notice that the required
functionality in the thin/service layer is much larger then the
functionaltity required in the tunnel/path layer; i.e. your "thin" layer is
essentially the "thickest" layer in the transport network. Tunnels/paths are
namely (metro, core) domain bound and as such NNI port cards do not have to
be equipped with lots of tunnel/path MEP fucntions. Because the
"thin"/service layer has to support multi-domain and multi-carrier
applications, the NNI port cards in PE nodes have to support additional
"thin"/service layer MEP functions to enable service protection switching,
carrier domain monitoring, fault localization and in some case link
connection monitoring.

[mv] PTN option 1 layer stack has a single "thin"/service layer (EVC), which
can be a world-wide "thin"/service layer. PTN option 2 has two
"thin"/service layers (EVC plus PW).

2. Where do you propose we do the work to change Ethernet OAM to math the
OAM present in MPLS-TP networks?

[mv] I do not propose that, and why should we do so. MPLS OAM is IP based,
while Ethernet OAM is transport network based. MPLS-TP OAM should also be
transport network based OAM. It is simpler to reuse existing transport
entwork based OAM then to redesign IP based OAM to fit the transport
network. Especially as the MPLS-TP technology is unable to support all the
necessary services, and has to be complemented by Ethernet technology to be
a complete solution (including support for mp2mp and rmp services). 

Regards,
Maarten

Cheers,
Adrian
----- Original Message -----
From: "Maarten Vissers" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 23, 2009 8:30 PM
Subject: Re: [mpls-tp] WK
LastCallondraft-ietf-mpls-tp-oam-requirements-02.txt

Markus,

Regards,
Maarten

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

Hi Maarten,

Regards
Markus

Erleben, was verbindet.

-----Ursprüngliche Nachricht-----

Loa,

Regards,
Maarten

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: woensdag 22 juli 2009 15:00
To: Maarten Vissers
Cc: 'Martin Vigoureux'; [email-masked]; 'MPLS-TP ad hoc'
Subject: Re: [mpls-tp] WK Last Call

All,

/Loa

should be stateless.
>> 23) T-MPLS OAM should allow for a stateless layer network 
>> interworking (also known as service interworking) between T-MPLS 
>> (based on [ITU-T

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 23 Jul 2009 22:46:08 +0100

Maarten,

1. Why do you assume that all technologies that build packet transport 
networks must provide the same services in the same way and are not able to 
behave differently? This is a fundamental question. It does not detract from 
your goal of providing a uniform packet transport network, but it suggests 
that your goal should be met by a (possibly) thin layer than runs over all 
packet technologies to unify them at the same functional level. It is in 
that layer that you would run e2e PN OAM services. This frees the network 
technologies to develop independently and leverage the behaviours of their 
own technologies.

Cheers,
Adrian
----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 23, 2009 8:30 PM
Subject: Re: [mpls-tp] WK 

Markus,

Regards,
Maarten

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

Hi Maarten,

Regards
Markus

Erleben, was verbindet.

-----Ursprüngliche Nachricht-----

Loa,

Regards,
Maarten

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: woensdag 22 juli 2009 15:00
To: Maarten Vissers
Cc: 'Martin Vigoureux'; [email-masked]; 'MPLS-TP ad hoc'
Subject: Re: [mpls-tp] WK Last Call

All,

/Loa

should be stateless.

--

---

From: <[email-masked]>
Date: Fri, 24 Jul 2009 10:03:35 +0100

Maarten,

> a complete solution (including support for mp2mp and rmp services).

I think your assertion that Ethernet OAM is naturally 'transport OAM' and
therefore automatically a better starting point than MPLS OAM is false.

802.1ag (on which Y.1731 is based/aligned) was not AFAIK targetted as
transport OAM as indicated in it's title "IEEE Standard for Local and
Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 5:
Connectivity Fault Management".

Yes Ethernet OAM can be used in transport networks but AFAIK additional
design was required in ITU to do that. I see no reason why MPLS OAM cannot
also be used (with some additional design) to do the same.

What is important is that the functional behaviour MPLS-TP OAM aligns with
that required by transport networks, the exact PDU format/mechanism is of
secondary importance IMO.

Ben

---

From: [email-masked]
Date: Fri, 24 Jul 2009 10:12:55 +0800

maaten,
thank you for your explaining. I reviewed your slides. IMO. for your 
option solution 1, I think it is unnecessary to encapsulate all kinds of 
services by the way of EVC.
option solution 2 maybe be used in the future packet transport networks 
under a few special conditions

best regards
liu 

收件人

Liu,
 
I have attached a couple of slides in which I illustrate two layer stacks 
which you find in the packet transport network.
The first layer stack deploy the EVC as service layer (slide 1), the 
second layer stack deploys the PW and EVC as service layers (slide 2).
As customers don't care which service layer technologies are being 
deployed by the different parts of the network, it will be necessary to 
interconnect both packet transport network alternatives at some time in 
future. This is illustrated in slide 3. For the Line type services (e.g. 
E-LINE, TDM, ATM, FR, ..) it will be required to interwork the EVC 
carrying those services in one part of the network with the PW carrying 
those same services in the other part of the network.
 
Regards,
Maarten

hi.all, 

best regards 
liu

收件人

All,

/Loa

reverse
an

-- 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.
[附件 "ptn-service-layers-00.pdf" 被 刘国满180323/user/zte_ltd 删除]

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 24 Jul 2009 12:43:23 +0200

Ben,

You have missed that Ethernet OAM has been started in ITU-T as part of
making Ethernet technology a transport network technology. IEEE at a later
stage joined and standardized in 802.1ag a subset of the ITU-T defined
Ethernet OAM for transport networks standardized in Y.1731. I.e. just the
opposite from what you wrote. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 24 juli 2009 11:04
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] WK

Maarten,

On 24/07/2009 08:49, "Maarten Vissers" <[email-masked]> wrote:
> From: Adrian Farrel [mailto:[email-masked]] 2. Where do you 
> propose we do the work to change Ethernet OAM to math the OAM present 
> in MPLS-TP networks?
> 
> [mv] I do not propose that, and why should we do so. MPLS OAM is IP 
> based, while Ethernet OAM is transport network based. MPLS-TP OAM 
> should also be transport network based OAM. It is simpler to reuse 
> existing transport entwork based OAM then to redesign IP based OAM to 
> fit the transport network. Especially as the MPLS-TP technology is 
> unable to support all the necessary services, and has to be 
> complemented by Ethernet technology to be a complete solution (including
support for mp2mp and rmp services).

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Jul 2009 10:16:42 -0400

Maarten,

	Just because Ethernet OAM is being worked in the ITU-T does not mean
that it now is "naturally transport OAM". Ben is correct here in stating
that while Ethernet OAM can be used in transport networks it does need
additional design. Thus I would go further in Ben's assertion and
say that I see no reason why MPLS OAM cannot be used as the mechanism
(with some additional design).  As we all know, it too is widely
deployed, and I would assert is more closely bound the the basic
mechanisms of MPLS-TP than Ethernet OAM is.

	--Tom

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 24 Jul 2009 07:36:20 -0700

Tom,

Impeccable reasoning.  I have always been under the impression that the
point of this exercise was to use MPLS technology, extended as necessary
in a manner consistent with the design precepts of MPLS.

I also think that if one wanted to work on ethernet OAM/ethernet PW OAM,
the natural place for that would be L2VPN, where, I think, there is
already ongoing work in this area.

Thanks,

John  

> From: Thomas Nadeau [mailto:[email-masked]] 
> Sent: Friday, July 24, 2009 7:17 AM
> To: Maarten Vissers
> Cc: [email-masked]
> Subject: Re: [mpls-tp] 
> WKLastCallondraft-ietf-mpls-tp-oam-requirements-02.txt
> 
> 
> 	Maarten,
> 
> 	Just because Ethernet OAM is being worked in the ITU-T 
> does not mean that it now is "naturally transport OAM". Ben 
> is correct here in stating that while Ethernet OAM can be 
> used in transport networks it does need additional design. 
> Thus I would go further in Ben's assertion and say that I see 
> no reason why MPLS OAM cannot be used as the mechanism (with 
> some additional design).  As we all know, it too is widely 
> deployed, and I would assert is more closely bound the the 
> basic mechanisms of MPLS-TP than Ethernet OAM is.
> 
> 	--Tom
> 
> 
> 
> > Ben,
> >
> > making Ethernet technology a transport network technology. 
> IEEE at a 
> > later stage joined and standardized in 802.1ag a subset of 
> the ITU-T 
> > defined Ethernet OAM for transport networks standardized in Y.1731. 
> > I.e.
> > just the
> > From: [email-masked] 
> > [mailto:[email-masked]
> > ]
> > I think your assertion that Ethernet OAM is naturally 
> 'transport OAM' 
> > and therefore automatically a better starting point than 
> MPLS OAM is 
> > false.
> >
> > Yes Ethernet OAM can be used in transport networks but AFAIK 
> > additional design was required in ITU to do that. I see no 
> reason why 
> > MPLS OAM cannot also be used (with some additional design) 
> to do the 
> > same.
> >
> > What is important is that the functional behaviour MPLS-TP 
> OAM aligns 
> > with that required by transport networks, the exact PDU 
> > format/mechanism is of secondary importance IMO.
> >
> > Ben
> >

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 24 Jul 2009 16:49:08 +0200

Tom,

> while Ethernet OAM can be used in transport networks it does need
additional design

Can you clarify what you mean with this statement.

As far as I am aware of, there is no need for any additional design to
deploy Y.1731 OAM in the Ethernet layers of the packet transport network.

To deploy Y.1731 OAM PDUs in the MPLS-TP layers of the transport network
does need a little bit of additional design for the LBM, as indicated in
draft-bhh-mpls-tp-oam-y1731. The MIP identification located in the DA field
of the Ethernet OAM header has to be replaced by a MIP identification in the
LBM PDU payload area. This is a similar change as made in 802.1Qay to reuse
the Ethernet LBM PDU as ESP LBM PDU.

The Y.1731 OAM PDUs can then be combined with either an Ethernet OAM header
,or an MPLS-TP OAM header plus an either an Ethernet label (VLAN Tag), or a
MPLS-TP label as illustated in the figure below (also attached). The main
differences are in the label formats and in the OAM header formats.

Regards,
Maarten

PS. These considerations do not change the requirement that it is necessary
to support stateless interworking between Ethernet OAM and MPLS-TP PW OAM.

-----Original Message-----
From: Thomas Nadeau [ <mailto:[email-masked]>
mailto:[email-masked]]
Sent: vrijdag 24 juli 2009 16:17
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] WK
LastCallondraft-ietf-mpls-tp-oam-requirements-02.txt

        Maarten,

        Just because Ethernet OAM is being worked in the ITU-T does not mean
that it now is "naturally transport OAM". Ben is correct here in stating
that while Ethernet OAM can be used in transport networks it does need
additional design. Thus I would go further in Ben's assertion and say that I
see no reason why MPLS OAM cannot be used as the mechanism (with some
additional design).  As we all know, it too is widely deployed, and I would
assert is more closely bound the the basic mechanisms of MPLS-TP than
Ethernet OAM is.

        --Tom

> making Ethernet technology a transport network technology. IEEE at a
> later stage joined and standardized in 802.1ag a subset of the ITU-T
> [ <mailto:[email-masked]>
mailto:[email-masked]
>> From: Adrian Farrel [ <mailto:[email-masked]>
mailto:[email-masked]] 2. Where do you
> I think your assertion that Ethernet OAM is naturally 'transport OAM'
> and therefore automatically a better starting point than MPLS OAM is
> false.
>
> additional design was required in ITU to do that. I see no reason why
> MPLS OAM cannot also be used (with some additional design) to do the
> same.
>
> What is important is that the functional behaviour MPLS-TP OAM aligns
>  <https://www.ietf.org/mailman/listinfo/mpls-tp>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 24 Jul 2009 10:18:15 -0700

Maarten,

I don't monitor this mailing list actively but today, the email below
caught my attention. 

I beg the difference. I introduced one of the first contribution for
Ethernet OAM in IEEE in June 2003 (refer to url below) and then
introduced corresponding contributions to ITU-T in August 2003. If you
think ITU work precede IEEE, can you point me to any contributions prior
to August 2003 which covered this subject as comprehensively as I did in
my contributions. 

http://www.ieee802.org/1/files/public/docs2003/IEEE-Provider-Bridges-OAM
-June03.ppt

Anyway, it doesn't matter which SDO started first, the fact of matter is
both 802.1aq and Y.1731 were done in lock step as the same people
actively participated in both groups (including you). BTW, 802.1ag was
not done for transport application as you know.

Cheers,
Ali  

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Friday, July 24, 2009 3:43 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] 
> You have missed that Ethernet OAM has been started in ITU-T 
> as part of making Ethernet technology a transport network 
> technology. IEEE at a later stage joined and standardized in 
> 802.1ag a subset of the ITU-T defined Ethernet OAM for 
> transport networks standardized in Y.1731. I.e. just the 
> [mailto:[email-masked]]
> 'transport OAM' and therefore automatically a better starting 
> point than MPLS OAM is false.
> 
> 802.1ag (on which Y.1731 is based/aligned) was not AFAIK 
> targetted as transport OAM as indicated in it's title "IEEE 
> Standard for Local and Metropolitan Area Networks Virtual 
> Bridged Local Area Networks Amendment 5:
> reason why MPLS OAM cannot also be used (with some additional 
> design) to do the same.
> 
> OAM aligns with that required by transport networks, the 
> exact PDU format/mechanism is of secondary importance IMO.
> 
> Ben
>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 27 Jul 2009 09:32:35 +0200

Ali,

The first Ethernet OAM contibutions were from NTT in the Jan 2002 SG13
meeting.
http://www.itu.int/md/T01-SG13-020122-D-0190/en
http://www.itu.int/md/T01-SG13-020122-D-0189/en
Those contributions were followed up by contributions in Oct/Nov 2002 and
July 2003 SG13 meetings.
http://www.itu.int/md/T01-SG13-021029-D-0291/en (Canada)
http://www.itu.int/md/T01-SG13-021029-D-0264/en (NTT)
http://www.itu.int/md/T01-SG13-030721-D-0435/en (Fujitsu)
http://www.itu.int/md/T01-SG13-030721-D-0419/en (NTT)
http://www.itu.int/md/T01-SG13-030721-D-0418/en (NTT)
http://www.itu.int/md/T01-SG13-030721-D-0412/en (NTT)
http://www.itu.int/md/T01-SG13-030721-D-0410/en (Alcatel)
http://www.itu.int/md/T01-SG13-030721-D-0409/en (Alcatel)
http://www.itu.int/md/T01-SG13-030721-D-0408/en (Alcatel)
http://www.itu.int/md/T01-SG13-030721-D-0404/en (BT)
http://www.itu.int/md/T01-SG13-030721-D-0403/en (Hitachi)
http://www.itu.int/md/T01-SG13-030721-D-0402/en (Hitachi)
http://www.itu.int/md/T01-SG13-030721-D-0401/en (Hitachi)
http://www.itu.int/md/T01-SG13-030721-D-0400/en (Hitachi)
http://www.itu.int/md/T01-SG13-030721-D-0383/en (PMC)
http://www.itu.int/md/T01-SG13-030721-D-0382/en (PMC)
http://www.itu.int/md/T01-SG13-030721-D-0381/en (PMC)
http://www.itu.int/md/T01-SG13-030721-D-0364/en (Nortel, PMC)
http://www.itu.int/md/T01-SG13-030721-D-0363/en (Nortel, PMC)
http://www.itu.int/md/T01-SG13-030721-D-0346/en (Cisco)
http://www.itu.int/md/T01-SG13-030721-D-0345/en (Cisco)
http://www.itu.int/md/T01-SG13-030721-D-0344/en (Cisco)
http://www.itu.int/md/T01-SG13-030721-D-0343/en (Cisco)
http://www.itu.int/md/T01-SG13-030721-D-0342/en (Cisco)
http://www.itu.int/md/T01-SG13-030721-D-0341/en (Cisco)
http://www.itu.int/md/T01-SG13-030721-D-0334/en (USA)
http://www.itu.int/md/T01-SG13-030721-D-0333/en (USA)
http://www.itu.int/md/T01-SG13-030721-D-0332/en (USA)

> Anyway, it doesn't matter which SDO started first, the fact of matter
> is both 802.1aq and Y.1731 were done in lock step as the same people
> actively participated in both groups (including you). 

I agree completely.

> BTW, 802.1ag was not done for transport application as you know.

I know. That is why in ITU-T we standardized in Y.1731 Ethernet OAM for
transport networks, and IEEE and ITU-T made sure that there is common base
between the 802.1ag and Y.1731 Ethernet OAM sets, on top of which IEEE has
included capabilities desired in non-transport networks and ITU-T has
included capabilitys desired in transport networks.

    ---------------------       -------------------------
    | transport network |       | non-transport network |
    |   specific OAM    |       |     specific OAM      |
    |    functions      |       |      functions        |
    ---------------------       -------------------------
              |                             |
           -------------------------------------
           | common set of basic OAM functions |
           -------------------------------------

Regards,
Maarten

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: vrijdag 24 juli 2009 19:18
To: Maarten Vissers; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp]

Maarten,

I don't monitor this mailing list actively but today, the email below caught
my attention. 

I beg the difference. I introduced one of the first contribution for
Ethernet OAM in IEEE in June 2003 (refer to url below) and then introduced
corresponding contributions to ITU-T in August 2003. If you think ITU work
precede IEEE, can you point me to any contributions prior to August 2003
which covered this subject as comprehensively as I did in my contributions. 

Anyway, it doesn't matter which SDO started first, the fact of matter is
both 802.1aq and Y.1731 were done in lock step as the same people actively
participated in both groups (including you). BTW, 802.1ag was not done for
transport application as you know.

Cheers,
Ali  

> I.e. just the opposite from what you wrote.
> 
> Regards,
> Maarten
> 
> MPLS OAM cannot also be used (with some additional
> design) to do the same.
>