Subject: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

From: Stewart Bryant <[email-masked]>
Date: Tue, 08 Jul 2008 12:35:08 +0100

We have a request to accept MPLS and Ethernet OAM Interworking

http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt

as a working group draft.

The authors thought that PWE3 had already agreed to this, but the
minutes of the last meeting do not say that, and in any case
we did not do a list poll.

Please can we have views on whether to accept as WG draft
by COB 15th July.

Thanks

Stewart/Danny

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

---

From: "Dinesh Mohan" <[email-masked]>
Date: Tue, 8 Jul 2008 11:08:24 -0400

Stewart, of course as an author I support this as a WG draft :-)

FYI...an updated version of the document is also available based on
feedback during the meeting and some further offline discussions:
http://www.ietf.org/internet-drafts/draft-mohan-pwe3-mpls-eth-oam-iwk-01
.txt

If we agree, this could be the version that can be accepted for working
group draft. 

---
Dinesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stewart Bryant
Sent: Tuesday, July 08, 2008 7:35 AM
To: pwe3
Subject: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

The authors thought that PWE3 had already agreed to this, but the
minutes of the last meeting do not say that, and in any case we did not
do a list poll.

Please can we have views on whether to accept as WG draft by COB 15th
July.

Thanks

Stewart/Danny

---

From: <[email-masked]>
Date: Tue, 8 Jul 2008 18:17:09 +0200

Hi all,

This draft provides the necessary complements to existing PWE3 WG documents in the case of Ethernet ACs. I support it as WG document.

Philippe. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Stewart Bryant
Envoyé : mardi 8 juillet 2008 13:35
À : pwe3
Objet : [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

The authors thought that PWE3 had already agreed to this, but the minutes of the last meeting do not say that, and in any case we did not do a list poll.

Please can we have views on whether to accept as WG draft by COB 15th July.

Thanks

Stewart/Danny

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 8 Jul 2008 09:42:33 -0700

Support it strongly.

As we saw in the last IETF, this draft was long over due !!

-Ali  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant (stbryant)
> Sent: Tuesday, July 08, 2008 4:35 AM
> To: pwe3
> The authors thought that PWE3 had already agreed to this, but 
> the minutes of the last meeting do not say that, and in any 
> case we did not do a list poll.
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 08 Jul 2008 18:43:39 +0200

+1

/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]
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 8 Jul 2008 19:03:03 +0200

Support 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Loa Andersson
Sent: Tuesday, July 08, 2008 19:44
To: Ali Sajassi (sajassi)
Cc: pwe3; Stewart Bryant (stbryant)
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

+1

/Loa

Ali Sajassi (sajassi) wrote:
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Stewart Bryant (stbryant)
>> minutes of the last meeting do not say that, and in any case we did 
>> not do a list poll.
>>

--
Loa Andersson

---

From: <[email-masked]>
Date: Tue, 8 Jul 2008 13:25:37 -0400

I support this draft becoming a WG draft. 

Thanks,
Nabil

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

Thanks

Stewart/Danny

---

From: "Simon Delord" <[email-masked]>
Date: Wed, 9 Jul 2008 03:31:16 +1000

Simon

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 8 Jul 2008 12:46:46 -0500

+1

--
Eric Gray
Principal Engineer
Ericsson  

> Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: Tuesday, July 08, 2008 1:03 PM
> To: Stewart Bryant (stbryant)
> Cc: Ali Sajassi (sajassi); pwe3
> Behalf Of
> by COB 15th

---

From: "David Allan" <[email-masked]>
Date: Tue, 8 Jul 2008 13:46:42 -0400

ditto
 
Dave

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Simon Delord
Sent: Tuesday, July 08, 2008 1:31 PM
To: [email-masked]; pwe3
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Simon

	
	
the

	Thanks
	
	Stewart/Danny

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 8 Jul 2008 13:53:54 -0400

In favor.

Hamid. 

> Behalf Of Stewart Bryant

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 8 Jul 2008 13:52:08 -0400

In favour. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dinesh Mohan
Sent: Tuesday, July 08, 2008 11:08 AM
To: Stewart Bryant (stbryant); pwe3
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

---
Dinesh

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

Thanks

Stewart/Danny

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Tue, 8 Jul 2008 19:55:21 +0200

support 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dinesh Mohan
Sent: dinsdag 8 juli 2008 17:08
To: [email-masked]; pwe3
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

---
Dinesh

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

Thanks

Stewart/Danny

---

From: "David Sinicrope" <[email-masked]>
Date: Tue, 8 Jul 2008 15:20:32 -0500

From: [email-masked] on behalf of Stewart Bryant
Sent: Tue 7/8/2008 7:35 AM
To: pwe3
Subject: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Thanks

Stewart/Danny

---

From: "Attila Takacs" <[email-masked]>
Date: Wed, 9 Jul 2008 08:50:41 +0200

Support.

Attila  

> Sent: Tuesday, July 08, 2008 1:35 PM
> To: pwe3

---

From: <[email-masked]>
Date: Wed, 9 Jul 2008 09:34:17 +0200

I support this draft becoming a Wg doc
Fred.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Stewart Bryant Envoyé : mardi 8 juillet 2008 13:35 À : pwe3 Objet : [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Thanks

Stewart/Danny

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 9 Jul 2008 08:10:03 -0400

How does this draft differ from draft-ietf-pwe3-oam-msg-map-06.txt  
which
is already a PWE3 WG item that is nearly complete?  It seems to me  
that after
a quick read, your document is providing the ethernet component that  
was agreed
to be in the mapping document.

	--Tom

---

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 9 Jul 2008 09:09:29 -0400

Tom,

The draft had been structured to allow integration into the
draft-ietf-pwe3-oam-msg-map however following discussions in both pwe3
and l2vpn WG, it was indicated that it would be worthwhile to progress
the draft independently. 

---
Dinesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Nadeau
Sent: Wednesday, July 09, 2008 8:10 AM
To: [email-masked]
Cc: pwe3
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

	How does this draft differ from
draft-ietf-pwe3-oam-msg-map-06.txt
which
is already a PWE3 WG item that is nearly complete?  It seems to me that
after a quick read, your document is providing the ethernet component
that was agreed to be in the mapping document.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 9 Jul 2008 09:13:54 -0400

I don't understand why. It overlaps with the draft in that area by  
%100. Monique and Luca are doing the
edits on the draft right now. What would be a more sensible approach  
would be to review what they are doing
and see what doesn't overlap and make sure it goes in there. The draft  
is nearly ready for WG LC, so it
would be more prudent to put it there. It would also be less confusing  
to see another draft on the same topic.

	--Tom

> Of
> that

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 9 Jul 2008 09:15:55 -0400

Dinesh,

I agree with Tom. It would be nice if this draft can subsequently
be folded into the oam-msg-map draft. It makes easier for everybody
to refer to just one document.

BTW, your draft is a much needed work that was missing from the 
oam-msg-map.

/himanshu

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Dinesh Mohan
> Sent: Wednesday, July 09, 2008 9:09 AM
> To: Thomas Nadeau; [email-masked]
> Cc: pwe3

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Wed, 9 Jul 2008 15:20:30 +0200

I tend to agree with Tom and Himanshu as well. Let's have a single draft
covering all OAM scenario's including also ETH interworking scenario's
with ATM, FR, Etc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shah, Himanshu
Sent: woensdag 9 juli 2008 15:16
To: Dinesh Mohan; Thomas Nadeau; [email-masked]
Cc: pwe3
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Dinesh,

I agree with Tom. It would be nice if this draft can subsequently be
folded into the oam-msg-map draft. It makes easier for everybody to
refer to just one document.

/himanshu

> Of Thomas Nadeau

---

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 9 Jul 2008 09:21:10 -0400

Himanshu, Tom,

Personally I am quite comfortable with either approach. I think that one
of the concerns expressed when it got presented in PWE3 was that
integrating it into oam-msg-map would likely delay oam-msg-map, which as
Tom noted is nearly done.

I think I will let the chairs and ADs also express their view on how the
discussions had unfolded. 

---
Dinesh

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 9:16 AM
To: Mohan, Dinesh (CAR:NP02); Thomas Nadeau; [email-masked]
Cc: pwe3
Subject: RE: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Dinesh,

/himanshu

---

From: Luca Martini <[email-masked]>
Date: Wed, 09 Jul 2008 08:04:26 -0600

> to see another draft on the same topic.
I'm working on this now, I am finishing the ATm setions , then i'll 
include the ethernet part of this document.
Luca

---

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 9 Jul 2008 10:08:39 -0400

Luca, 

This is certainly a news to me!!! Is this already a foregone conclusion
- where is the process????

I, and so will other authors, will certainly appreciate some sort of
headup. 

---
Dinesh

-----Original Message-----
From: Luca Martini [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 10:04 AM
To: Thomas Nadeau
Cc: Mohan, Dinesh (CAR:NP02); Stewart Bryant; pwe3 pwe3; Monique-Jean
Morrow1

> %100. Monique and Luca are doing the edits on the draft right now. 
> What would be a more sensible approach would be to review what they 
> are doing and see what doesn't overlap and make sure it goes in there.

> The draft is nearly ready for WG LC, so it would be more prudent to 
> put it there. It would also be less confusing to see another draft on 
> the same topic.
>

>> draft-ietf-pwe3-oam-msg-map however following discussions in both 
>> pwe3 and l2vpn WG, it was indicated that it would be worthwhile to 
>> progress the draft independently.
>>
>> ---
>> Dinesh
>>
>> that after a quick read, your document is providing the ethernet 
>> component that was agreed to be in the mapping document.
>>
>>     --Tom
>>
>>
>>

---

From: <[email-masked]>
Date: Wed, 9 Jul 2008 16:47:28 +0200

Luca, Tom,

I have the same feeling as Dinesh.

The two options were proposed during the presentation and discussed during the last meeting. In my understanding it was requested by the chairs to keep documents separate in order not to delay the oam-map draft. If you had some concern with this decision it should have been preferable to raise it on the mailing list just following the meeting and not now.
In addition I think that the decision to merge both documents should be conditionned by a clear decision from the WG.

Regards,

Philippe.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dinesh Mohan
Envoyé : mercredi 9 juillet 2008 16:09
À : Luca Martini; Thomas Nadeau
Cc : Monique-Jean Morrow1; pwe3 pwe3; Stewart Bryant
Objet : Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Luca, 

I, and so will other authors, will certainly appreciate some sort of headup. 

---
Dinesh

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Wednesday, July 09, 2008 10:04 AM
To: Thomas Nadeau
Cc: Mohan, Dinesh (CAR:NP02); Stewart Bryant; pwe3 pwe3; Monique-Jean
Morrow1

> put it there. It would also be less confusing to see another draft on 
I'm working on this now, I am finishing the ATm setions , then i'll include the ethernet part of this document.
Luca

---

From: <[email-masked]>
Date: Wed, 9 Jul 2008 11:28:23 -0400

Hi Tom,
The mapping draft did not have the Ethernet component. We broguth up
that issue during the Hilly meeting of taking our draft and merging it
in. The concensus was to progress the Ethernet OAM draft independently.

Thanks,
Nabil

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

	--Tom

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 9 Jul 2008 08:53:10 -0700

I think, the two drafts should be kept separate. The two drafts have
different list of authors and lots of discussions and efforts have gone
into evaluating interoperability with different Ethernet mechanisms
including 802.1ag, ELMI, and link OAM. And I am not sure at this late
stage, it makes sense to have 10 editors on the oam-map-msg right before
the last call !!

Besides, the consensus as mentioned by Nabil below, was to progress each
of these draft separately.

Cheers,
Ali 

> Behalf Of [email-masked]
> Sent: Wednesday, July 09, 2008 8:28 AM
> To: [email-masked]; Stewart Bryant (stbryant)
> Cc: [email-masked]
> The mapping draft did not have the Ethernet component. We 
> broguth up that issue during the Hilly meeting of taking our 
> draft and merging it in. The concensus was to progress the 
> Ethernet OAM draft independently.
> 
> Thanks,
> Nabil
> 
> Behalf Of Thomas Nadeau
> is already a PWE3 WG item that is nearly complete?  It seems 
> to me that after a quick read, your document is providing the 
> ethernet component that was agreed to be in the mapping document.
> 
> 	--Tom
> 
> 
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 9 Jul 2008 11:59:59 -0400

Well here I agree with Dinesh.

It is one thing to intend to have a single document but other to
undercut the work already in progress, processed and discussed by other
WG members.

I support Dinesh's draft to be included in oam-msg-map and duely credited
to those authors and not have competing alternate text in oam-msg-map draft.

/himanshu

> Sent: Wednesday, July 09, 2008 10:09 AM
> To: Luca Martini; Thomas Nadeau
> Cc: Monique-Jean Morrow1; pwe3 pwe3; Stewart Bryant

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 9 Jul 2008 19:30:40 +0300

Luca and Dinesh

Quote from Philadelphia minutes :

   Yaakov Stein - this is important work. Have you also looked into .3ah? We need
   this covered too.
   Nabil: I thought we did, because we cover link level defects. We need to go back
   and make sure this is covered.
   Ali Sajassi: This is a very good comment. Counts for ELMI too in MEF.
   Luca Martini: I have asked for this years ago, and chairs did not want to put
   into. I am in favour of putting this into message mapping.
   Stewart - don't remember, but msg-map is quite mature
   Luca Martini - this will generate more interest again and we can progress this.
   Stewart - Monique is the editor and she just refreshed it. It would be good to
   review msg-map, and progress Ethernet separately as some more material to add.
   Yaakov Stein - agrees should be separate, and not hold up message map.
   Danny: is there consistent terminology with OAM and redundancy drafts?
   Nabil: The mapping draft is most advanced, and common authors with redundancy,
   so hope they are consistent, but need to check.

   Stewart: if existing OAM message mapping draft is nearly done, then keep
   separate so as not to hold up.

   Luca Martini: what will the IESG say without the lack of Ethernet?
   Stewart: put in informative reference to Ethernet doc. Co-authers need to add
   informative reference, and then we will last call it.
   George Swallow: The way the industry is going, the Ethernet is the  most
   important part.

I think we see that Tom/Luca's initiative to merge this into the oam-msg-map
draft was addressed, and that the majority wanted it to be kept separate.

I am sure that none of us expected to find two parallel versions of this work.

The decision was based on oam-msg-map taking too long.
If the present authors of oam-msg-map are now determined to push this through
QUICKLY, then I am not against cutting and pasting Dinesh's draft into oam-msg-map.
This may actually speed things up, as draft-mohan-pwe3-mpls-eth-oam-iwk
is not even a WG item yet.
Of course, if we do merge the documents, then the authors of the second need to be credited.
Since that would overflow the already extensive author list,
there could be 2 editors (e.g. <Luca OR Monique> AND Dinesh)
and the rest of the authors be pushed down to an author's section.

However, I would like to reiterate what I said in Philadelphia.
I am not a great fan of OAM mapping at all, and wouldn't care
if the present oam-msg-map draft died a natural death.
Ethernet to Ethernet PW OAM interworking is an evil, but frequently a necessary one.
Work on it needs to be expedited.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dinesh Mohan
Sent: Wednesday, July 09, 2008 5:09 PM
To: Luca Martini; Thomas Nadeau
Cc: Monique-Jean Morrow1; pwe3 pwe3; Stewart Bryant
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Luca,

---
Dinesh

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Wednesday, July 09, 2008 10:04 AM
To: Thomas Nadeau
Cc: Mohan, Dinesh (CAR:NP02); Stewart Bryant; pwe3 pwe3; Monique-Jean
Morrow1

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 9 Jul 2008 12:05:16 -0500

Just to add to what Yaakov says, the message mapping draft 
version currently available in the draft repository says
explicitly that it does not include Ethernet OAM (therefore
- presumably - does not include Ethernet OAM interworking).

The wording chosen in the message mapping draft appears to
be a "scope statement" rather than an editorial note (such
as might be included if this was work for further study in
that draft).

--
Eric Gray
Principal Engineer
Ericsson  

> Behalf Of Yaakov Stein
> Sent: Wednesday, July 09, 2008 12:31 PM
> To: Dinesh Mohan; Luca Martini; Thomas Nadeau
> Behalf Of Dinesh Mohan
> I'm working on this now, I am finishing the ATm setions , 
> then i'll include the ethernet part of this document.
> Luca
> 
> >     --Tom
> >
> >
> >> Tom,
> >>

---

From: Luca Martini <[email-masked]>
Date: Wed, 09 Jul 2008 11:39:53 -0600

> as might be included if this was work for further study in
That will change shortly.
The message mapping draft is in a very poor state. Have you read it 
recently ?
I will be done shortly with a new version , but I'm not sure we can get 
all the changes needed by the deadline.
What is missing:

- ATM and static PW/BFD message mapping
- Handling of Standby state.
- All ethernet message mapping.
- L2TP message mapping is broken.

Luca

>>>     I don't understand why. It overlaps with the draft in 
>>>       
>> that area by
>>
>>     
>>> are doing and see what doesn't overlap and make sure it 
>>>       
>> goes in there.
>>
>>     
>>> put it there. It would also be less confusing to see 
>>>       
>> another draft on
>>     
>>> the same topic.
>>>
>>>       
>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>         
>> On Behalf
>>     
>>>> Of Thomas Nadeau
>>>>> minutes of the last meeting do not say that, and in any 
>>>>>           
>> case we did
>>     
>>>>> not do a list poll.
>>>>>

---

From: <[email-masked]>
Date: Wed, 9 Jul 2008 20:18:04 +0100

Hi Dinesh and Ali,

A few observations on the draft and the subject of OAM in general that
you might like to take into account:

1	Despite what some folks having been trying to do in ITU the OAM
required for each of the 3 network modes (cl-ps, co-ps and co-cs) is not
the same.  For example, AIS is mentioned in the draft.  AIS has its
roots in co-cs mode PDH/TDM networks.  AIS is about alarm suppression
(in co mode clients *above* a server failure) not generating alarms.  It
was a direct consequence of old TTL logic when, on failure, the logic
'floated' to +5V (ie binary 1).....so a binary all 1s signal was the
natural indication of failure here.  Note in particular it is a passive
signal....in the sense that we don't have to actively create special
traffic units to mimic it as we would in any packet network.  Further,
since the co-cs mode is characterised by a constant bit rate signal AIS
is naturally a constant stream of binary all 1s (when replacing the
traffic signal).

AIS is however not a natural signal in packet networks.  And whilst it
is understandable to want to have an AIS/FDI OAM function in co-ps mode
layer networks (on the assumption they have proper single source
connections, ie p2p or p2mp constructs only) it has no meaning in cl-ps
mode networks, eg IP, Ethernet.  And this, of course, is why IEEE saw
fit to deprecate AIS in 802.1ag for Ethernet OAM.

My view is that IETF should align its position with that of the IEEE
standards when dealing with Ethernet OAM.

2	I note that the BDI (or RDI) function has been piggy-backed in
CC messages in both Y.1731 and 802.1ag.  In the case of co-cs or co-ps
mode layer networks this only works for symmetrical bidirectional
connections, ie p2p constructs only.  It does not work for p2mp
connection constructs (as these cannot be bidirectionally symmetric) and
so a CC message and a BDI message need to be distinct/independent OAM
messages here.  This is something to bear in mind for GMPLS (controlled
co-cs mode layer network connections), MPLS and PWs (assuming the case
of both these supporting proper single source co-ps connections).

Now of course Ethernet is a cl-ps mode technology so we don't have
connections. However, if we make the OAM CC message a broadcast function
between MEPs then we force a condition of symmetry here and so one can,
in principle, piggyback BDI in CC messages.....the traffic of course can
be, and usually is, unicast (once SA MAC learning has taken place).  So
the first observation here is that the OAM is not exercising exactly the
same processing path as the traffic.  Further, the indiscriminate
broadcasting of BDI to N far-ends wrt to an unknown number of incoming
failures is hardly good practice (see section 7.5 in Y.1731).

However, the key point I am making here is the former one, ie when we
are dealing with proper co-cs or co-ps mode p2mp connections we cannot
piggyback BDI in CC messages.

3	It is a very, very bad idea to have client layer defects
reflected in a server layer network (be this DP/CP/MP).  I just noted
Yaakov also allude to this point in his mail 09 July 2008 17:31, viz:

"However, I would like to reiterate what I said in Philadelphia.
I am not a great fan of OAM mapping at all, and wouldn't care if the
present oam-msg-map draft died a natural death.
Ethernet to Ethernet PW OAM interworking is an evil, but frequently a
necessary one.
Work on it needs to be expedited."

Quite.....need to start getting these things right (here a transparent
client/server layer network relationship).

4	Final, and far more general, point....OAM needs to be uber
reliable...far more so than the intrinsic failure rate of the network it
resides in.  So defect detection/handling OAM needs to be as
simple/sparse as possible.  Collecting OAM (esp Perf Mon OAM)
information also has a real opex cost.  Ops folks will turn-off as much
OAM as they can...esp bloated/bad OAM (Y.1731 is bloated IMO).  I've
just noticed TCM (Tandem Connection Monitoring) has been added to the
PWE3 charter.  I would strongly advise IETF *not* to go here just
because others have included this in their standards.  This idea has
been around for many years in ITU and there are very good reasons why
very little of it is used in practice (I can spell this out if not
obvious).

Regards, Neil

> Sent: 08 July 2008 16:08
> FYI...an updated version of the document is also available 
> based on feedback during the meeting and some further offline 
> discussions:
> If we agree, this could be the version that can be accepted 
> for working group draft. 
> 
> ---
> Dinesh
>

---

From: <[email-masked]>
Date: Wed, 9 Jul 2008 17:14:09 -0400

Hi Luca,
I concur with Dinesh and the meeting minutes were clear. We actually
proposed the merging as reflected in the minutes Yakov sent out. The
concensus was to progress this draft independently as the other mapping
draft was in LC, considered to be wrapped up, and should not be delayed.
The MPLS-Ethernet OAM would have been a significant new addition. The
authors acted accordingly and sent out the new updated draft addressing
the comments in the meeting.

The Ethernet OAM was needed and I think you expressed that as well.
Since it was new most people did not want to hold up the mapping draft
you are working on that existed for a long time without Ethernet OAM or
Etehrnet-MPLS OAM interworking and went to LC without that. As pointed,
they were explicitely excluded. There was no effort to add that until
now!. There is now a draft on that topic on its own. The draft was well
accepted by the group and the decision was made to progress it
seperatly. 

Why would the seperation decision change now and how would that impact
the progress of either! However, that is probably a wider question to
the chairs. I am just reflecting what happened during the meeting and
would have helped to know that the decision changed somehow or did it?. 

It would also have been good to discuss how the existing Ethernet-MPLS
OAM Interworking draft could be merged with the other mapping draft if
the WG were to change the decision made at the meeting, as the work
exists already. There was no hesitation to do that in the beginning by
the authors (we proposed that) and the authors acted upon WG decision.
So, in what you mentioned below, are you proposing to the WG to merge
draft-mohan-pwe3-mpls-eth-oam-iwk-01.txt in the message mapping draft
again?  Just trying to get a clarification as to what is the intention
here and what is being proposed.

Thanks,
Nabil 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Luca Martini
Sent: Wednesday, July 09, 2008 1:40 PM
To: Eric Gray
Cc: Yaakov Stein; Monique-Jean Morrow1; pwe3 pwe3; Stewart Bryant
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Eric Gray wrote:
> Just to add to what Yaakov says, the message mapping draft version 
> currently available in the draft repository says explicitly that it 
> does not include Ethernet OAM (therefore
> The wording chosen in the message mapping draft appears to be a "scope

> statement" rather than an editorial note (such as might be included if

> this was work for further study in that draft).
>
>   

Luca

>> Of Yaakov Stein
>>    Nabil: The mapping draft is most advanced, and common authors with

>> redundancy,
>>    George Swallow: The way the industry is going, the Ethernet is the

>> most
>>    important part.
>>
>> I think we see that Tom/Luca's initiative to merge this into the 
>> oam-msg-map draft was addressed, and that the majority wanted it to 
>> be kept separate.
>>
>> If the present authors of oam-msg-map are now determined to push this

>> through QUICKLY, then I am not against cutting and pasting Dinesh's 
>> draft into oam-msg-map.
>> This may actually speed things up, as 
>> draft-mohan-pwe3-mpls-eth-oam-iwk is not even a WG item yet.
>> Since that would overflow the already extensive author list, there 
>> could be 2 editors (e.g. <Luca OR Monique> AND Dinesh) and the rest 
>> of the authors be pushed down to an author's section.
>>

>> Of Dinesh Mohan

---

From: Luca Martini <[email-masked]>
Date: Wed, 09 Jul 2008 15:15:32 -0600

> I, and so will other authors, will certainly appreciate some sort of
I said I would do this in the last IETF meeting .. it just look a bit 
too long ...
I'm gong to take the text and put it into the msg-mapping draft.
We can then have a discussion in Dublin, and finish it within the next rev.

Luca

---

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 9 Jul 2008 17:22:10 -0400

Luca,

Where is what you said in the last meeting reflected? Where was the
agreement reached? I am sure I was attending the same meeting, or wasn't
I.

I repeat this is news to me still and I am sure is for others as well. I
have no recollection of this from the pwe3 meeting and also we
summarized the same in the FYI presentation in L2VPN which is also
reflected in the minutes in both groups.

I do not understand this sudden change in stance. In any case, I and
possibly others do not appreciate your sidelining the entire
discussion/agreement in the meeting and insisting on your position.

Hopefully we can restore some sanity here!!!!

---
Dinesh

-----Original Message-----
From: Luca Martini [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 5:16 PM
To: Mohan, Dinesh (CAR:NP02)
Cc: Thomas Nadeau; Stewart Bryant; pwe3 pwe3; Monique-Jean Morrow1
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

I said I would do this in the last IETF meeting .. it just look a bit
too long ...
I'm gong to take the text and put it into the msg-mapping draft.
We can then have a discussion in Dublin, and finish it within the next
rev.

Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 09 Jul 2008 16:43:50 -0600

> Hopefully we can restore some sanity here!!!!
Well , What is the problem here ?
The msg map document clearly needs new attention. We want to avoid 
another fiasco like in the VCCV document case.
It seems your document expired, and there was clear consensus that the 
ethernet part needs to be included in the PWE3 specifications.

So if we want to avoid another fiasco , like in the VCCV document case, 
Let's stop calling for LCs just to get the document off the list , and 
let's work on actually finishing to write the Message mapping draft.

If you want to review and edit it before we send this revision, I can 
send you the source tomorrow night. ( I need it back by Saturday afternoon )

Luca

>>> are doing and see what doesn't overlap and make sure it goes in
>>>       
> there.
>   
>>>     
>>>       
>>   
>>

---

From: "Simon Delord" <[email-masked]>
Date: Thu, 10 Jul 2008 08:57:07 +1000

Hi everyone,

it seems to me that the minutes clearly states:
"Stewart: if existing OAM message mapping draft is nearly done, then keep
          separate so as not to hold up."

Can we please keep both documents separated so the oam-message-mapping can
go to LC?
It has now been more than 3 years of efforts put into the
oam-message-mapping (BTW thanks Monique, Tom, Mustapha, Matthew, Peter and
Dave for all your efforts there and a great vendor cooperation) and Service
Providers need some standard they can refer to ASAP.

Furthermore rushing the ethernet section may not be a good idea, l don't
have any issue with looking at two standards (oam-message-mapping / ethernet
OAM interworking) if they do not overlap, actually it makes the reading
easier :-)

Regards,

Simon

---

From: Luca Martini <[email-masked]>
Date: Wed, 09 Jul 2008 20:08:06 -0600

>           separate so as not to hold up."
The problem is that the current OAM message mapping draft is not nearly 
done.
It is missing the following:
- ATM and static PW/BFD message mapping
- Handling of Standby state.
- All ethernet message mapping.
- L2TP message mapping is broken.

This document would not pass LC without this work being added.

Luca

> Can we please keep both documents separated so the oam-message-mapping 
> can go to LC?
> oam-message-mapping (BTW thanks Monique, Tom, Mustapha, Matthew, Peter 
> and Dave for all your efforts there and a great vendor 
> cooperation) and Service Providers need some standard they can refer 
> to ASAP.
>  
> Furthermore rushing the ethernet section may not be a good idea, l 
> don't have any issue with looking at two standards 
> (oam-message-mapping / ethernet OAM interworking) if they do not 
> overlap, actually it makes the reading easier :-)
>  
> Regards,
>  
> Simon
>
>
> 2008/7/10 <[email-masked] <mailto:[email-masked]>>:
>
>
>
>     Hi Luca,
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of
>     Luca Martini
>     >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     >> Of Yaakov Stein
>     >>    Luca Martini: I have asked for this years ago, and chairs
>     did not
>     >> want to put
>     >>    Yaakov Stein - agrees should be separate, and not hold up
>     message
>     >> map.
>     if the
>     >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     >> Of Dinesh Mohan
>     >> From: Luca Martini [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >>>> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     >>>>
>     >> On Behalf
>     >>
>     >>>> Of Thomas Nadeau
>     >>>> To: [email-masked] <mailto:[email-masked]>
>     >>>> Cc: pwe3
>     >>>> Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
>     as WG
>     >>>> draft
>     >>>>
>     >>>>
>     to me
>     >>>>> [email-masked] <mailto:[email-masked]>
>     >>>> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 9 Jul 2008 23:19:43 -0400

> This document would not pass LC without this work being added.

Does not seem to be the case based on the following notes from pwe3
minutes:

Luca Martini: what will the IESG say without the lack of Ethernet? 
Stewart: put in informative reference to Ethernet doc. Co-authers need
to add 
informative reference, and then we will last call it.

Dinesh

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 Jul 2008 10:51:07 +0300

Stewart, Danny and all,

> On Behalf Of [email-masked]
> Sent: Wednesday, July 09, 2008 10:18 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> as WG draft
... snipped ...
> I've just noticed TCM (Tandem Connection Monitoring) has been added to the
... snipped to the end...

I wonder how Tandem Connection Monitoring for PWs has made its way into the published Charter
as one of the milestones. It is not discussed/defined in the Charter itself and it has not been mentioned
on the WG mailing list for the last 7+ months (including the versions of the Charter posted for the WG
discussion during the re-chartering process).

I share Neil's concerns about this topic. In particular, Low-Order Path TCM (defined by ITU-T in addition to the
SONET High-Order Path TCM) is a feature known both for implementation complexity and lack of actual
deployments... Do we really need more of the same in PWE3?

Regards,
        Sasha

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Jul 2008 11:51:16 +0100

Sasha

TCM for PWs is in the JWT report: draft-bryant-mpls-tp-jwt-report-00.pdf

It was added when we were asked to flesh out deliverables to support 
MPLS-TP.

If as you and Neil suggest it's hard to make work, then that will be 
clear if/when
we see drafts defining it, and we can proceed accordingly.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 Jul 2008 14:30:17 +0300

Stewart,

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Thursday, July 10, 2008 1:51 PM
> To: Alexander Vainshtein
> Cc: Danny McPherson; [email-masked]; [email-masked];
> Alik Shimelmits; Jeremy Brayley; Moshe Aharon
> Subject: Re: Tandem Connection Monitoring in the new PWE3 Chapter
... snipped ...
> draft-bryant-mpls-tp-jwt-report-00.pdf
[Sasha] Suspected that. And, BTW, it is not in the draft itself, it is in the JWT report
(http://www.ietf.org/MPLS-TP_overview-22.pdf) referenced by the draft.
The report also explains that SDH/OTN TCM is a special case of "segment OAM", so maybe
we should use a more appropriate term.
> It was added when we were asked to flesh out deliverables to support
[Sasha] A pity it has not ever been raised explicitly on the list.
And, as I read it, the JWT report does not distinguish between LSPs and PWs
with regard to segment OAM (a.k.a. TCM). On the contrary, it mentions "nested"
segment OAM" (see Slide 16 Bullet 2, and the last bullet on Slide 35); and AFAIK,
PWs are not nested. So maybe the proper home for this work is the MPLS WG?
> clear if/when we see drafts defining it, and we can proceed accordingly.
>
[Sasha] Neil and I have raised not just the complexity issue, but also questioned
the usefulness of this feature.

---

From: "Newton, Jonathan" <[email-masked]>
Date: Fri, 11 Jul 2008 18:21:44 +0100

Hi Neil,

A quick query on the subject of AIS:

I understand your summary of the background of AIS, but there is surely
still a requirement for a triggered forward error indication of some
form?  ATM defined AIS cells for this function, so there is already a
precedent for this function in a co-ps network.

The problem that I foresee is that, although ethernet is inherently
cl-ps, Ethernet will be extensively used in a p2p manner, especially
when ethernet is used as a tail circuit to an IP service.  In this case,
I think that an AIS function is valid.  If this is not available, would
we not need to have CCM enabled in all cases?

Maybe the problem stems from the fact that SPs are often trying to use
Ethernet, that is inherently connectionless, in a connection oriented
manner!

> Quite.....need to start getting these things right (here a 
> transparent client/server layer network relationship).
Yes, seems to be the root of a lot of issues we are running into! Is it
worth noting that Y.1731 seems to have defined a server layer:
"NOTE - A Server MEP needs to support ETH-AIS function, as described in
sub-clause 7.4, where the Server/ETH adaptation function is required to
issue frames with ETH-AIS information upon detection of defect at the
Server layer by the Server layer termination and/or adaptation
function."

Cheers,
~Jon.

> Behalf Of [email-masked]
> Sent: 09 July 2008 20:18
> A few observations on the draft and the subject of OAM in 
> general that you might like to take into account:
> 
> required for each of the 3 network modes (cl-ps, co-ps and 
> co-cs) is not the same.  For example, AIS is mentioned in the 
> draft.  AIS has its roots in co-cs mode PDH/TDM networks.  
> AIS is about alarm suppression (in co mode clients *above* a 
> server failure) not generating alarms.  It was a direct 
> consequence of old TTL logic when, on failure, the logic 
> 'floated' to +5V (ie binary 1).....so a binary all 1s signal 
> was the natural indication of failure here.  Note in 
> particular it is a passive signal....in the sense that we 
> don't have to actively create special traffic units to mimic 
> it as we would in any packet network.  Further, since the 
> co-cs mode is characterised by a constant bit rate signal AIS 
> is naturally a constant stream of binary all 1s (when 
> replacing the traffic signal).
> 
> AIS is however not a natural signal in packet networks.  And 
> whilst it is understandable to want to have an AIS/FDI OAM 
> function in co-ps mode layer networks (on the assumption they 
> have proper single source connections, ie p2p or p2mp 
> constructs only) it has no meaning in cl-ps mode networks, eg 
> IP, Ethernet.  And this, of course, is why IEEE saw fit to 
> deprecate AIS in 802.1ag for Ethernet OAM.
> 
> My view is that IETF should align its position with that of 
> the IEEE standards when dealing with Ethernet OAM.
> 
> 
> 
> CC messages in both Y.1731 and 802.1ag.  In the case of co-cs 
> or co-ps mode layer networks this only works for symmetrical 
> bidirectional connections, ie p2p constructs only.  It does 
> not work for p2mp connection constructs (as these cannot be 
> bidirectionally symmetric) and so a CC message and a BDI 
> message need to be distinct/independent OAM messages here.  
> This is something to bear in mind for GMPLS (controlled co-cs 
> mode layer network connections), MPLS and PWs (assuming the 
> case of both these supporting proper single source co-ps connections).
> 
> Now of course Ethernet is a cl-ps mode technology so we don't 
> have connections. However, if we make the OAM CC message a 
> broadcast function between MEPs then we force a condition of 
> symmetry here and so one can, in principle, piggyback BDI in 
> CC messages.....the traffic of course can be, and usually is, 
> unicast (once SA MAC learning has taken place).  So the first 
> observation here is that the OAM is not exercising exactly 
> the same processing path as the traffic.  Further, the 
> indiscriminate broadcasting of BDI to N far-ends wrt to an 
> unknown number of incoming failures is hardly good practice 
> (see section 7.5 in Y.1731).
> 
> However, the key point I am making here is the former one, ie 
> when we are dealing with proper co-cs or co-ps mode p2mp 
> connections we cannot piggyback BDI in CC messages.
> 
> 
> reflected in a server layer network (be this DP/CP/MP).  I 
> just noted Yaakov also allude to this point in his mail 09 
> July 2008 17:31, viz:
> 
> Quite.....need to start getting these things right (here a 
> transparent client/server layer network relationship).
> 
> 
> reliable...far more so than the intrinsic failure rate of the 
> network it resides in.  So defect detection/handling OAM 
> needs to be as simple/sparse as possible.  Collecting OAM 
> (esp Perf Mon OAM) information also has a real opex cost.  
> Ops folks will turn-off as much OAM as they can...esp 
> bloated/bad OAM (Y.1731 is bloated IMO).  I've just noticed 
> TCM (Tandem Connection Monitoring) has been added to the
> PWE3 charter.  I would strongly advise IETF *not* to go here 
> just because others have included this in their standards.  
> This idea has been around for many years in ITU and there are 
> very good reasons why very little of it is used in practice 
> (I can spell this out if not obvious).
> 
> Regards, Neil
> 
> 
> 
> > If we agree, this could be the version that can be accepted for 
> > working group draft.
> > 
> > ---
> > Dinesh
> > 
> > Of Stewart Bryant

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: <[email-masked]>
Date: Sat, 12 Jul 2008 09:16:28 +0100

Thank you Jon....some attempted answers in-line: 
[email-masked] wrote 11 July 2008 18:22

> I understand your summary of the background of AIS, but there 
> is surely still a requirement for a triggered forward error 
> indication of some form?  ATM defined AIS cells for this 
> function, so there is already a precedent for this function 
> in a co-ps network.
NH=> Yes, that is true.  However, it's not as obvious a requirement as
you might think.  FDI requires a persistent binding of a client and
server layer network, ie the sever, on failure, needs to be sure who its
clients are in order to inject FDI into them....it's not much good if
those clients change.  This long-lasting client/server permanence has
been a traditional truth in nested PDH/SDH co-cs mode transport layer
networks...which is of course where the notion of AIS comes from as I
explained.  But what if the clients can change more dynamically?  Start
by envisioning co-cs or co-ps mode SVC clients (eg co-cs PSTN) which
have shrinking holding times......in the limit this become a single
message of a cl-ps mode client layer network.  So if we imagine a link
connection in such a client layer network (ie a single hop between 2
adjacent client layer nodes which is provided by a network connection in
some lower layer server network) it becomes quite clear that we cannot
assign any permanence between a specific client communications instance
and their use (or not) of that link (=server network connection).
Hopefully you can see that.  And this is why it makes no sense
whatsoever to carry over the idea of AIS/FDI into cl-ps mode layer
networks and explains why IEEE had the good sense to take AIS out of
802.1ag.

We discussed the issue of FDI within BT when considering the OAM we
would want for PBB-TE (co-ps mode based on using the original cl-ps
Ethernet traffic unit), and on balance we considered it was not a good
idea.  However, the CV and BDI OAM functions are essential....but they
should NOT be piggybacked in order that we can properly address the p2mp
connection case.

But as I also noted in my mail, a key requirement on OAM (at least that
used for defect detection) is that it is super reliable, and that tends
to mean as sparse as possible of function with minimal configuration.
Anything that requires lots of config (and the TCM stuff factors heavily
here - see later comment) is really not a requirement.
> 
> The problem that I foresee is that, although ethernet is 
> inherently cl-ps, Ethernet will be extensively used in a p2p 
> manner, especially when ethernet is used as a tail circuit to 
> an IP service.  In this case, I think that an AIS function is 
> valid.  If this is not available, would we not need to have 
> CCM enabled in all cases?
NH=> Please remember that CV and FDI are very different.  CV checks THIS
layer network, FDI is an indication of failure (possibly from a CV flow
detected defect) in a LOWER layer network.  I've seen folks try and 'do
away' with CV and just use FDI...it's a mistake.....as to get FDI SOME
layer network has to be able to detect it's failures, and it won't
always be the section layer, ie very bottom of stack, that can do this.
No CV means you are blind to defects in your layer network, you only see
server layer defects IFF they generate a FDI into your layer network
across the adaptation function...and as explained above, FDI/AIS is not
such a great idea as folks might think.
> 
> Maybe the problem stems from the fact that SPs are often 
> trying to use Ethernet, that is inherently connectionless, in 
> a connection oriented manner!
NH=> Well yes....but the mere fact that special topology consideration
exists (ie the p2p degenerate network case you mentioned above) is not
the general network case.  
> transparent 
> Yes, seems to be the root of a lot of issues we are running 
> into!
NH=> It is rather important/fundamental....but it is violated all over
the place.  I'll say no more on the matter here.

> Is it worth noting that Y.1731 seems to have defined a 
> server layer:
> "NOTE - A Server MEP needs to support ETH-AIS function, as 
> described in sub-clause 7.4, where the Server/ETH adaptation 
> function is required to issue frames with ETH-AIS information 
> upon detection of defect at the Server layer by the Server 
> layer termination and/or adaptation function."
NH=> This is all about TCM.  One might like to observe that in any
general layer network only the access points are fixed....intermediate
points can change, and indeed MUST change if we want to have resiliency.
(You may be struck here by the similarities to the point I made earlier
regarding FDI and how one can't assume a permanence between a client
communications instance and the links (=server layer connections) it is
using at any epoch).  Now try and get your head around how you would
manage the config of such (moveable) intermediate points, especially if
you were trying to get accurate perf mon (PM) data across failures and
restorations.  TCM sounds good on paper, but show me the management
solutions for PM across dynamic changes of routing.  Hint=> I've looked
quite closely at doing this at end points that are time invariant/fixed
in the past and this is not a simple problem even here (eg pkts
in-flight, clock differences) now extrapolate that problem to a raft of
nested TCM levels that are not invariant/fixed....let me know when you
have an answer for PM in TCM across failures/restorations ;-)

Regards, Neil

> > Of [email-masked]
> > Sent: 09 July 2008 20:18
> > co-cs) is not the same.  For example, AIS is mentioned in 
> the draft.  
> > AIS has its roots in co-cs mode PDH/TDM networks.
> > AIS is about alarm suppression (in co mode clients *above* a server 
> > failure) not generating alarms.  It was a direct consequence of old 
> > TTL logic when, on failure, the logic 'floated' to +5V (ie binary 
> > 1).....so a binary all 1s signal was the natural indication 
> of failure 
> > here.  Note in particular it is a passive signal....in the 
> sense that 
> > we don't have to actively create special traffic units to 
> mimic it as 
> > we would in any packet network.  Further, since the co-cs mode is 
> > characterised by a constant bit rate signal AIS is naturally a 
> > constant stream of binary all 1s (when replacing the 
> traffic signal).
> > 
> > is understandable to want to have an AIS/FDI OAM function in co-ps 
> > mode layer networks (on the assumption they have proper 
> single source 
> > connections, ie p2p or p2mp constructs only) it has no meaning in 
> > cl-ps mode networks, eg IP, Ethernet.  And this, of course, is why 
> > IEEE saw fit to deprecate AIS in 802.1ag for Ethernet OAM.
> > 
> the IEEE 
> > connection constructs (as these cannot be bidirectionally 
> symmetric) 
> > and so a CC message and a BDI message need to be 
> distinct/independent 
> > OAM messages here.
> > This is something to bear in mind for GMPLS (controlled co-cs mode 
> > layer network connections), MPLS and PWs (assuming the case of both 
> > these supporting proper single source co-ps connections).
> > 
> > connections. However, if we make the OAM CC message a broadcast 
> > function between MEPs then we force a condition of symmetry 
> here and 
> > so one can, in principle, piggyback BDI in CC 
> messages.....the traffic 
> > of course can be, and usually is, unicast (once SA MAC learning has 
> > taken place).  So the first observation here is that the OAM is not 
> > exercising exactly the same processing path as the traffic. 
>  Further, 
> > the indiscriminate broadcasting of BDI to N far-ends wrt to 
> an unknown 
> > number of incoming failures is hardly good practice (see 
> section 7.5 
> > in Y.1731).
> > 
> just noted 
> transparent 
> > reliable...far more so than the intrinsic failure rate of 
> the network 
> > it resides in.  So defect detection/handling OAM needs to be as 
> > information also has a real opex cost.
> bloated/bad OAM 
> > (Y.1731 is bloated IMO).  I've just noticed TCM (Tandem Connection 
> > Monitoring) has been added to the
> > because others have included this in their standards.
> > This idea has been around for many years in ITU and there are very 
> > good reasons why very little of it is used in practice (I can spell 
> > this out if not obvious).
> > 
> > Regards, Neil
> > 
> > 
> > 
> This e-mail has been scanned for viruses by the Cable & 
> Wireless e-mail security system - powered by MessageLabs. For 
> more information on a proactive managed e-mail security 
> service, visit http://www.cw.com/uk/emailprotection/ 
> 
> The information contained in this e-mail is confidential and 
> may also be subject to legal privilege. It is intended only 
> for the recipient(s) named above. If you are not named above 
> as a recipient, you must not read, copy, disclose, forward or 
> otherwise use the information contained in this email. If you 
> have received this e-mail in error, please notify the sender 
> (whose contact details are above) immediately by reply e-mail 
> and delete the message and any attachments without retaining 
> any copies.
>  
> Cable and Wireless plc

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 15 Jul 2008 21:12:31 +0200

Stewart,

TCM is not hard to make work, as we have been proving in OTN and Ethernet
where we have included this capability from the begin. 

In SDH it was hard to add TCM to a large existing network, as this TCM
capability was developed 4 years after the initial SDH specification was
approved. 
By that time lots of LO VC equipment was in the network that could not be
upgraded. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stewart Bryant
Sent: 10 July 2008 12:51
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Jeremy Brayley; Danny McPherson;
Alik Shimelmits
Subject: Re: [PWE3] Tandem Connection Monitoring in the new PWE3 Chapter

Alexander Vainshtein wrote:
> I wonder how Tandem Connection Monitoring for PWs has made its way 
> into the published Charter as one of the milestones. It is not 
> discussed/defined in the Charter itself and it has not been mentioned 
> on the WG mailing list for the last 7+ months (including the versions of
the Charter posted for the WG discussion during the re-chartering process).
>
> I share Neil's concerns about this topic. In particular, Low-Order 
> Path TCM (defined by ITU-T in addition to the SONET High-Order Path 
> TCM) is a feature known both for implementation complexity and lack of
actual deployments... Do we really need more of the same in PWE3?
Sasha

If as you and Neil suggest it's hard to make work, then that will be clear
if/when we see drafts defining it, and we can proceed accordingly.

- Stewart

---

From: "Italo Busi" <[email-masked]>
Date: Wed, 16 Jul 2008 14:56:13 +0200

Sasha,

I agree with Stewart that we can judge the complexity of Tandem Connection
Monitoring (TCM) only after we have a description of the solution.

Regarding the argument about the usefulness due to the TCM implementation for
SDH LO (Lower Order) I would highlight that:

- some implementations of LO TCM actually exist

- TCM in SDH was not well-designed (in fact SDH TCM cannot be nested): as a
consequence non-intrusive monitoring has been used as a work-around to "emulate"
the TCM capabilities (thus supporting nesting)

- this work-around has the disadvantage that the monitoring capabilities of an
operator depends on the OAM features that are enabled on the e2e path

- this work-around worked in SDH networks also because segmented protections are
usually based on a 1+1 mechanisms. In packet networks where 1:1 mechanisms are
expected to be used more extensively than 1+1 mechanisms, the work-around used
in SDH does not work any more and TCM are required to monitor the working and
protectino sub-paths

- the limitations of SDH TCM are well known within ITU-T and as a consequence
the requirement to support nested TCM has since then be considered very
important in all the subsequent OAM designs within ITU-T (OTN, Ethernet as well
as T-MPLS)

Italo

> Behalf Of Alexander Vainshtein
> Sent: Thursday, July 10, 2008 1:30 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Jeremy Brayley; 
> Danny McPherson; Alik Shimelmits

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 15 Jul 2008 21:46:02 +0200

Sasha,

>From a functional modelling perspective, a MS-PW is an 'LSP that carries
non-IP client signals'. 
A SS-PW could also be an 'LSP that carries non-IP client signals', or it
could just be a 'demultiplex label' for a non-IP client signal carried
directly inside a MPLS tunnel.

The MS-PW connection can have more then one owner, and each owner wants to
monitor its segment. 
Owners can be a service provider, a network operator but also a SNC
Protection Switching application. 
As with many other technologies that get popular, MS-PWs may in the longer
term be starting/ending in customer domains; when this happens the MS-PW
gets also the customer as one of its owners.

There is one MS-PW connection, and inside this connection there are one or
more monitoring (called Maintenance Entity Group) levels active.
These MEG levels are nested.
This design was made to prevent that the activation/deactivation of a MEG
level would change the connection.

The top MEG level can be referred to as Network Connection Monitoring (NCM).
The bottom MEG level can be referred to as Link Connection Monitoring (LCM).
The intermediate MEG levels can be referred to as Tandem Connection
Monitoring (TCM).

In SDH, ATM, OTN and Ethernet the MEG levels use identifiers within the
frame. 
Also in T-MPLS we had upgraded an existing field in the OAM frame to
identify the MEG level.

Note: ATM VP connections have two MEG levels (end-to-end=NCM, segment=TCM).
ATM VC connections also have two MEG levels (end-to-end=NCM, segment=TCM).
Both MEG levels are used in ATM networks.

The JWT has decided that for MPLS-TP we will not use this well known method
to identify MEG levels in a connection. 
Instead the JWT has decided to create a new server connection (new LSP) for
every TCM and LCM MEG level.
When you activate a TCM or LCM level, the original connection will be
deleted in the part of the segment that you want to monitor and a new server
connection will be set up in this segment; at the endpoints of this new
server connection the original connection signal will be mapped into the new
connection. When a TCM or LCM level is to be removed, the reverse changes
have to be applied. 
This could become a network management and/or control plane nightmare. 
It would be much simpler/better not to chagne the PW connection. But this
requires an alternative encoding of the MEG levels inside the OAM frames;
there are two options available, the Ethernet MEG level encoding (Y.1731,
802.1ag) or the T-MPLS MEG level encoding (ex-draft G.8114).

Regards,
Maarten

-----Original Message-----
Alexander Vainshtein
Sent: 10 July 2008 13:30

Stewart,

> Cc: Danny McPherson; [email-masked]; [email-masked]; Alik 
> Shimelmits; Jeremy Brayley; Moshe Aharon
... snipped ...
> draft-bryant-mpls-tp-jwt-report-00.pdf
[Sasha] Suspected that. And, BTW, it is not in the draft itself, it is in
the JWT report
(http://www.ietf.org/MPLS-TP_overview-22.pdf) referenced by the draft.
The report also explains that SDH/OTN TCM is a special case of "segment
OAM", so maybe we should use a more appropriate term.
[Sasha] A pity it has not ever been raised explicitly on the list.
And, as I read it, the JWT report does not distinguish between LSPs and PWs
with regard to segment OAM (a.k.a. TCM). On the contrary, it mentions
"nested"
segment OAM" (see Slide 16 Bullet 2, and the last bullet on Slide 35); and
AFAIK, PWs are not nested. So maybe the proper home for this work is the
MPLS WG?
> clear if/when we see drafts defining it, and we can proceed accordingly.
[Sasha] Neil and I have raised not just the complexity issue, but also
questioned the usefulness of this feature.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 17 Jul 2008 10:59:51 +0300

Italo,
Lots of thanks for a detailed clarification.

I defer to your statement that LO TCM in SDH was not well designed and, in fact, could not be nested.

I think that that the following example clarifies my position regarding TCM:

ANSI has partially followed ITU-T and defined STS TCM (the equivalent of HO TCM) for SONET networks. It did not define VT TCM.
However, the latest available version of GR-253 I could put my hands on does not specify ANY TCM-related requirements that the SONET NEs must match (just mentions  that this functionality has been defined).

To me this is a good indication that the SONET operators somehow manage reasonably well without TCM.

In a more generic way, I think that there are two mindsets when it comes to defining the  OAM functions:

Approach 1: "What else potentially useful (including useful in some bizarre scenarios) can be squeezed into the given amount of bits and bytes?"

Approach 2: "What is the minimum that the operators really cannot do without?"

IMHO (and FWIW),  Approach 2 is preferable, especially if augmented with some extension potential, while Approach 1 may easily result not just in "bloated" (I quote Neil)  specs but also in more expensive equipment.

My 2c.
        Sasha

> From: Italo Busi [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2008 3:56 PM
> To: Alexander Vainshtein; [email-masked]
> 'Danny McPherson'; Alik Shimelmits
> Subject: RE: [PWE3] Tandem Connection Monitoring in the new
> PWE3 Chapter
>
> Sasha,
>

---

From: <[email-masked]>
Date: Thu, 17 Jul 2008 14:14:57 +0100

Well put Sasha,

We seem to get either feast or famine wrt OAM...neither is required.
The other, and in some ways more worrying trend, is an attempt to try
and treat all 3 network modes as though they are the same.....and of
course, OAM is only one component in this respect.

But I must come back to a key principle here.  If a network
technology/mode:
-	is used inappropriately for a given service need
-	has been specified in way that makes it complex to operate with
many potential defects....and one key area here is the management of
resource, especially when (for certain services) this must be
deterministic
-	has an intrinsically high defect rate
then it is these issues that need to be addressed, not overloading the
network with lots of OAM.

When the 3 modes are each properly functionally specified
(over-specification is as bad as under-specification) and used correctly
in concert then many otherwise very hard problems become easy, eg if we
could have simple mode selection of message/file => cl-ps and stream =>
co-ps (co-cs emulation) the we would not need any QoS classes per
technology/mode at all (this is NOT the same as a survivability
importance semantic).  However, I don't really want to get into this
bigger picture problem here, but I hope most folks can sort-of see what
I am hinting at wrt attacking complexity by thinking outside the 'one
mode/technology can do-it-all' traditional box.

At the end of the day our biggest enemy is indeed complexity...and this
metric is not reducing.

But now let me come back to the TCM issue.  It sounds wonderful on
paper.  And it usually comes with an argument that different parties
want to peer their networks.  However, this is NOT generally true except
for well defined *top-of-stack* public service networks, eg Internet,
PSTN.  Let me do a quick aside to illustrate why peering when we are NOT
at the top-of-stack is a bad idea and unnecessary anyway.

Start aside=>

If we want to peer-interwork 2 network technologies then its generally a
very good idea if they belong to the same network mode.  If they don't
there will be a significant functional mismatch in many DP and CP
components, which is some cases will not be resolvable (noting that we
usually do not peer the MP components for security reasons, and we
similarly restrict the scope of CP components at key interworking
points, ie UNIs and ENNIs).  In particular it is NOT sufficient to
consider only the OAM component of the DP as I have seen some folks
focus on.  

But let's assume we have excellent alignment of all the DP/CP components
in 2 same-mode technologies such that we can interwork them as peers.  A
key question we should now pose is 'what is the DP client component that
is passed transparently between the 2 network partitions?'  

If we in are in a top-of-stack public network situation there are (by
definition) no higher layer networks...so we must be dealing directly
with applications....or more accurately their message/file/stream
end-system application adaptation functions, eg UDP/TCP/RTP in IP, the
AALs in ATM, the u/A-law encoding of (voice/stream only) in PSTN.   But
many technologies simply don't have such end-system application
adaptation functions, eg PDH, SDH, Ethernet, MPLS....or at least they
don't have them right now.  However, if you REALLY want to peer 2
technologies this is the issue you must ultimately confront...and one
will have either (i) a end-system application adaptation function
protocol conversion (if not the same) issue or (ii) force the 2
technologies to use the same end-system application adaptation
functions.  {Further aside=> check out FRF8 for dealing with ATM/FR
interworking, esp in the case of stream applications which essentially
resorts to handwaving here.}

So that is one scenario.....but what if we are NOT at the top-of-stack?
Well, we must have a higher layer network in that case and we are not
dealing directly with end-system application adaptation functions.
Indeed, we now realise that it is the higher layer network (and all of
it's 3 DP/CP/MP components) that is the thing that must be passed
transparently between the 2 server layer peer partitions.  But hang on a
moment...if this is the case then the ONLY practical way of dealing with
this is to terminate all DP/CP/MP components of each of the server layer
partitions at the interworking function.  In other words we have the
classical client/server layer network relationship case when we are NOT
at the top-of-stack.  And of course this is what we see in practice, eg
if I want to build an IP network then I can choose to support the link
connections in that IP layer network using SDH_VC4, PDH_E1, ATM,
Ethernet, etc server layer network connections (ie end-end in the server
layer) which are fully terminated at the IP layer network nodes and
operate completely independent and functionally disjoint from one
another.

In other words, when we are NOT at the top-of-stack there is NO peer
interworking requirement at all between the server layer technologies
that support a higher layer network!

So folks need think very carefully about what they really mean when they
advocate 'peer interworking' of different or even the same mode
technologies.

<= End Aside

Having dispensed with the argument for TCM between different parties if
we are NOT in a top-of-stack public network service case, let's now have
look at some of it's other consequences.

A network (any mode/technology) has a set of fixed access points (let's
put mobile networks to one side here). Communication takes place between
such access points.  To get between 2 access points A and B say we
require to calculate a route in a graph of nodes and link connections.
In co mode networks we create a connection (which MUST have the property
of single source if we want to also define resource determinism) and
this persists for the lifetime of a communication, ie all traffic units
from A to B always follow the same path.  We don't create connections in
a cl-ps technology and traffic units from A to B can follow different
paths, in principle on a traffic unit by traffic unit basis.

In all cases we can quite sensibly define MEPs for these A/B end-points
and monitor this for connectivity/performance.  But what about all the
intermediate points the path from A to B goes through?

Let's take the traditional transport case of very long-holding co
connections first as this is most sympathetic to TCM and where it had
its origins. Because the route is pinned we can sensibly define nested
sublayer segments of the path and create MEPs here.  (And of course this
would be a single party doing this in a non top-of-stack case for the
reasons I outlined earlier wrt why we usually don't want/need-to
peer-partition networks when not in public service context).  Works
fine.  Now what happens if we want to change the route of the path from
A to B, eg planned works or a failure/restoration event?  Well, A and B
stay in the same place so those MEPs don't alter and we can indeed
accurately measure any outage/performance impact of changing the
routing.  But what about all the intermediate points?  We need to
deconfigure/deactivate the old ones and configure/activate some new
ones...assuming we *know* where the new path is going to be and we have
all the CP/MP/OSS tools to do this.

So there is config cost here (and indeed it is also a potential source
of unreliability) but it is doable I suppose.  We will have some rather
tricky issues wrt accurate performance metric accounting across such
changes at the nested intermediate points.

Now consider the co mode SVC case...or more generally, let's assume we
are starting to shrink the holding times of the connections of the
previous case.  The end-points A and B stay the same...so no problems
there.  But we now have the question 'at what holding time would one not
consider it worth the bother/cost of configuring/deconfiguring all the
intermediate points?'.

And I suppose we also should be asking the question 'do we have the
CP/MP/OSS tools to do this config/deconfig anyway AND at the required
construct/destruct rates involved?'  Seems like a law of diminishing
returns to me even assuming we had such tools and we thought TCM was a
good idea as the holding times shrink.

Now consider the cl-ps mode case.  Here the theoretical holding time is
a rather small single traffic unit....and we also will not usually know
where the traffic will be directed, eg post failures.  Hmmm, seems to be
a real problem.  Well, we could create a set of pinch-points in the
network topology (essentially reduce the graph connectivity to 1 here)
so that the nested intermediate points must persist across changes in
routing.  But this is hardly a good idea as we are now penalising our
ability to provide resilience just so we can watch these TCM points do
their thing.

We might, alternatively, overlay a fixed set of nested TCM levels in the
cl-ps network and pretend it's a co mode network...essentially what is
in Y.1731.  I suppose at this point we also have to observe that
Ethernet is unusual as a cl-ps mode technology as it always must force a
connectivity of one per VLAN...so it is most tempting to believe TCM is
viable here, just like the long-holding co mode case which I started
with.  But this thinking cannot be applied to cl-ps mode networks which
have a directed routing function like IP and can have a rich/arbitrary
meshing with traffic units taking any route they like (in principle) and
not being forced through a fixed network path.

Think I've said enough here for folks to mull over....but I'll leave you
with 2 final thoughts:
-	if TCM was that great don't you think we'd done loads of it by
now even where most appropriate?
-	if TCM is that universally great, can we see it implemented in
IP first please before applying it elsewhere ;-)

Regards, Neil

> From: Alexander Vainshtein [mailto:[email-masked]] 
> Sent: 17 July 2008 09:00
> To: Italo Busi
> Cc: Harrison,N,Neil,CXM R; [email-masked]; Jeremy Brayley; 
> 'Danny McPherson'; Alik Shimelmits; [email-masked]
> I defer to your statement that LO TCM in SDH was not well 
> designed and, in fact, could not be nested.
> 
> ANSI has partially followed ITU-T and defined STS TCM (the 
> equivalent of HO TCM) for SONET networks. It did not define VT TCM.
> However, the latest available version of GR-253 I could put 
> my hands on does not specify ANY TCM-related requirements 
> that the SONET NEs must match (just mentions  that this 
> functionality has been defined).
> 
> To me this is a good indication that the SONET operators 
> somehow manage reasonably well without TCM.
> 
> In a more generic way, I think that there are two mindsets 
> when it comes to defining the  OAM functions:
> 
> Approach 1: "What else potentially useful (including useful 
> in some bizarre scenarios) can be squeezed into the given 
> amount of bits and bytes?"
> 
> IMHO (and FWIW),  Approach 2 is preferable, especially if 
> augmented with some extension potential, while Approach 1 may 
> easily result not just in "bloated" (I quote Neil)  specs but 
> also in more expensive equipment.
> 
> My 2c.
>         Sasha
> 
> 
> 
> 
> 
> 
> 
> > Cc: [email-masked]; [email-masked]; Jeremy Brayley; 'Danny 
> > McPherson'; Alik Shimelmits
> > I agree with Stewart that we can judge the complexity of Tandem 
> > Connection Monitoring (TCM) only after we have a description of the 
> > solution.
> >
> > Regarding the argument about the usefulness due to the TCM 
> > implementation for SDH LO (Lower Order) I would highlight that:
> >
> > consequence non-intrusive monitoring has been used as a 
> work-around to 
> > "emulate"
> > - this work-around has the disadvantage that the monitoring 
> > capabilities of an operator depends on the OAM features that are 
> > enabled on the e2e path
> >
> > - this work-around worked in SDH networks also because segmented 
> > protections are usually based on a 1+1 mechanisms. In 
> packet networks 
> > where
> > 1:1 mechanisms are
> > expected to be used more extensively than 1+1 mechanisms, the 
> > work-around used in SDH does not work any more and TCM are 
> required to 
> > monitor the working and protectino sub-paths
> >
> > - the limitations of SDH TCM are well known within ITU-T and as a 
> > consequence the requirement to support nested TCM has since then be 
> > considered very important in all the subsequent OAM designs within 
> > ITU-T (OTN, Ethernet as well as T-MPLS)
> >
> > Italo
> >
> > > Of Alexander Vainshtein
> > > Cc: [email-masked]; [email-masked]; Jeremy Brayley; Danny 
> > > McPherson; Alik Shimelmits
> > > [Sasha] Suspected that. And, BTW, it is not in the draft 
> itself, it 
> > > is in the JWT report
> > > The report also explains that SDH/OTN TCM is a special case of 
> > > "segment OAM", so maybe we should use a more appropriate term.
> > > >
> > > And, as I read it, the JWT report does not distinguish 
> between LSPs 
> > > and PWs with regard to segment OAM (a.k.a. TCM). On the 
> contrary, it 
> > > mentions "nested"
> > > segment OAM" (see Slide 16 Bullet 2, and the last bullet on Slide 
> > > 35); and AFAIK, PWs are not nested. So maybe the proper home for 
> > > this work is the MPLS WG?
> > > >
> > > [Sasha] Neil and I have raised not just the complexity issue, but 
> > > also questioned the usefulness of this feature.
> > >
> > > > - Stewart
> > > >
> > > >
> > > >
> > > >

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 17 Jul 2008 17:32:12 +0200

Hello Sasha,

You wrote:

> Italo, Lots of thanks for a detailed clarification.
> 

What about the other points Italo mentioned?
Some of them are not documented by the ITU-T but implementations
by vendors on request of their customers to provide more than
a single layer of TCM in their networks.

> ANSI has partially followed ITU-T and defined STS TCM (the equivalent
> of HO TCM) for SONET networks. It did not define VT TCM.

I have the most recent version of ANSI T1.105 (2006) and that
defines in section 3.63 high-order (STS) tandem connections
*AND* low-order (VT) tandem connections.
In section 8.1.4 the Tandem connection layer is described.

There is even a document dedicated to Tandem Connection Maintenance
by ANSI: T1.105.02 (1994).

> However, the
> latest available version of GR-253 I could put my hands on does not
> specify ANY TCM-related requirements that the SONET NEs must match
> (just mentions  that this functionality has been defined).

The most recent version of GR-253 is from 1999.
It is based on T1.105 and should have been udated long ago.
However there was no funding to do that since Belcore became
Telcordia.

> manage reasonably well without TCM.

In the last couple of years I have hardly see any RFQ asking for
GR-253 compliance. They require compliance with ITU-T and ANSI
standards.

> Approach 1: "What else potentially useful (including useful in some
> bizarre scenarios) can be squeezed into the given amount of bits and
> bytes?"

We are currently in a requirements phase and not in a solution
phase, so sqeezing of the last bit is still out of scope.

> Approach 2: "What is the minimum that the operators really cannot do

User data?

> IMHO (and FWIW),  Approach 2 is preferable, especially if augmented
> with some extension potential, while Approach 1 may easily result not
> just in "bloated" (I quote Neil)  specs but also in more expensive
> equipment.
> 
> My 2c. Sasha

My 2 (euro)c, cheers, Huub.

>> -----Original Message----- From: Italo Busi
>> [mailto:[email-masked]] Sent: Wednesday, July 16,
>> 2008 3:56 PM To: Alexander Vainshtein; [email-masked] Cc:
>> [email-masked]; [email-masked]; Jeremy Brayley; 'Danny
>> McPherson'; Alik Shimelmits Subject: RE: [PWE3] Tandem Connection
>> Monitoring in the new PWE3 Chapter
>> 
>> Sasha,
>> 
>> - TCM in SDH was not well-designed (in fact SDH TCM cannot be 
>> nested): as a consequence non-intrusive monitoring has been used as
>> a work-around to "emulate" the TCM capabilities (thus supporting
>> nesting)
>> 
>> protections are usually based on a 1+1 mechanisms. In packet
>> networks where 1:1 mechanisms are expected to be used more
>> extensively than 1+1 mechanisms, the work-around used in SDH does
>> not work any more and TCM are required to monitor the working and 
>> protectino sub-paths
>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein 
>>> Sent: Thursday, July 10, 2008 1:30 PM To: [email-masked] Cc:
>>> [email-masked]; [email-masked]; Jeremy Brayley; Danny
>>> McPherson; Alik Shimelmits Subject: Re: [PWE3] Tandem Connection
>>> Monitoring in the new PWE3 Chapter
>>> 
>>> Stewart,
>>> 
>>>> -----Original Message----- From: Stewart Bryant
>>>> [mailto:[email-masked]] Sent: Thursday, July 10, 2008 1:51
>>>> PM To: Alexander Vainshtein Cc: Danny McPherson; [email-masked];
>>>> [email-masked]; Alik Shimelmits; Jeremy Brayley; Moshe
>>>> Aharon Subject: Re: Tandem Connection Monitoring in the new
>>>> PWE3 Chapter
>>> ... snipped ...
>>>> Sasha
>>>> 
>>> [Sasha] A pity it has not ever been raised explicitly on the
>>> list. And, as I read it, the JWT report does not distinguish 
>>> between LSPs and PWs with regard to segment OAM (a.k.a. TCM). On
>>> the contrary, it mentions "nested" segment OAM" (see Slide 16
>>> Bullet 2, and the last bullet on Slide 35); and AFAIK, PWs are
>>> not nested. So maybe the proper home for this work is the MPLS
>>> WG?
>>>> clear if/when we see drafts defining it, and we can proceed
>>> accordingly. [Sasha] Neil and I have raised not just the
>>> complexity issue, but also questioned the usefulness of this
>>> feature.
>>> 
>>>> - Stewart
>>>> 
>>>> 
>>>> 
>>>> 
>>> _______________________________________________ pwe3 mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/pwe3
>>> 
>> 
> _______________________________________________ pwe3 mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/pwe3
> 

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 17 Jul 2008 18:49:53 +0300

Huub,
Lots of thanks for the response.

Please see some comments/answers inline below.

My 3.5 (US) cents to top your two (Euro) ones..
        Sasha

> From: Huub van Helvoort [mailto:[email-masked]]
> Sent: Thursday, July 17, 2008 6:32 PM
> To: Alexander Vainshtein
> Cc: Italo Busi; [email-masked]; Alik Shimelmits; Jeremy Brayley
[Sasha] I would be very interested to hear from an operator that
has deployed LO TCM in its SDH (or SONET) network.
Meanwhile I defer to Neil.

> equivalent
> It is based on T1.105 and should have been updated long ago.
[Sasha] At my previous job (Axerra Networks) I've been dealing with GR-253 Issue 4
dated December 2005. As I've said, it mentioned T1.105.02 (1994), but did not pose
any requirements for TCM. So maybe you should update your library...
> phase, so squeezing of the last bit is still out of scope.
>

---

From: "Italo Busi" <[email-masked]>
Date: Mon, 21 Jul 2008 17:22:36 +0200

Neil,

Could you please clarify what are your specific concerns with TCM in "the
traditional transport case of very long-holding co connections"?

I was not able to find any in your mail.

Thanks, Italo

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 17, 2008 3:15 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > From: Alexander Vainshtein 
> [mailto:[email-masked]] 
> > Sent: 17 July 2008 09:00
> > To: Italo Busi
> > > nested): as a
> > > > accordingly.

---

From: <[email-masked]>
Date: Tue, 22 Jul 2008 10:17:00 +0100

Thanks Italo, you asked 21 July 2008 16:23:

> Could you please clarify what are your specific concerns with 
> TCM in "the traditional transport case of very long-holding 
> co connections"?
> 

NH=> In my mail I was showing how TCM is not a universally applicable
idea, and specifically why:
-	when not at top-of-network stack (any mode) one can't appeal to
a multi-party ownership driver for TCM;
-	as holding times reduce the notion of constructing/destructing
nested sublayers becomes less viable.....in the limit one has the cl-ps
mode (IP say) and here I'd regard TCM as not valid at all.

Indeed I did say the most sympathetic case for TCM is long-holding
connections....traditionally what one would associate with
bottom-of-stack transport networks such as SDH, WDM, and this is where
TCM has it's origin a decade or more ago.  The reason this is the most
sympathetic case is that it is the least dynamic wrt set-up/tear-down of
connections.  However, we have same TCM construction/destruction
implications and concerns here, they just happen at a lower rate.

Also remember what I said should be the guiding principles of OAM:
-	as simple/sparse as possible for the mode considered (noting
that OAM requirements are NOT the same for all the network modes)
because the defect detection/handling OAM must be significantly more
reliable than the network/connection it is monitoring;
-	a corollary of the above is minimum things to configure;
-	OAM also has a config/processing/collection cost...OPs folks
will happily turn-off as much OAM as they can...so its better not to
provide them with OAM features we would not consider as adding important
value.

There are secondary considerations such as knowing where traffic is to
be moved to wrt the destruction-of-old/construction-of-new TCM points
and MP/CP co-ordination, and how things like the synchronisation of any
performance measurements are to be handled across routing changes.  I've
never really understood how all this would work, or indeed where it is
all written down/standardised...are all these things documented anywhere
(even if only in patents)?

Having dispensed with the multi-party argument for TCM, one is left with
the single party ownership case. And given the same party owns the
connection end to end then the overwhelmingly more important requirement
is monitoring of the end-end OAM flow.

I also checked out the history of TCM and SDH with Andy Reid who was
intimately involved in all the key SDH standards at the time.  Here is
what Andy had to say on the matter:

" Non-intrusive monitoring was never a "work-around". It came first and
was the only requirement identified in all the main standards
development. It is fully baked into the standards and the standards were
created to support it. It was always understood that non-intrusive
monitoring would be the mainstay OAM mechanism.

TCM came along as a later proposal and it was mainly at the instigation
of one particular operator who was at the time concerned with putting
cross connects into an essentially PDH network. Even they were not sure
exactly how they wanted to use it but their timescales were tight and
money didn't seem to be a major problem. In order to get all the
standards fixed, we agreed that what is in the current SDH TCM was an
optional extra. It was also agreeable because we'd worked out that if
you XORed the new TCM byte value with the old TCM byte value and then
XORed the BIP with the answer, you could 'update' the BIP without
changing its check sum properties with the payload. If there was an
error in the frame, the BIP would stay errored even after the TCM
calculation. Had this trick not been possible, TCM for SDH would not
have been agreed.

As I'm aware, it is still the originally designed e2e monitor including
non-intrusive monitoring that is the overwhelmingly used monitor in SDH
and it has proven very reliable and fits well with operational
processes."

This hopefully helps flesh-out better why TCM has never found much
favour with us, even where it is most applicable, ie long-holding
bottom-of-stack transport network connections.  Perhaps other operators
have different views but I have not heard them so far.

regards, Neil
    
> > (over-specification is as bad as under-specification) and used 
> > correctly in concert then many otherwise very hard problems become 
> > easy, eg if we could have simple mode selection of message/file => 
> > cl-ps and stream => co-ps (co-cs emulation) the we would 
> not need any 
> > QoS classes per technology/mode at all (this is NOT the same as a 
> > survivability importance semantic).  However, I don't 
> really want to 
> > get into this bigger picture problem here, but I hope most 
> folks can 
> > sort-of see what I am hinting at wrt attacking complexity 
> by thinking 
> > outside the 'one mode/technology can do-it-all' traditional box.
> > 
> > At the end of the day our biggest enemy is indeed complexity...and 
> > this metric is not reducing.
> > 
> > want to peer their networks.  However, this is NOT generally true 
> > except for well defined *top-of-stack* public service networks, eg 
> > Internet, PSTN.  Let me do a quick aside to illustrate why peering 
> > when we are NOT at the top-of-stack is a bad idea and unnecessary 
> > anyway.
> > 
> > Start aside=>
> > 
> > If we want to peer-interwork 2 network technologies then 
> its generally 
> > a very good idea if they belong to the same network mode.  If they 
> > don't there will be a significant functional mismatch in 
> many DP and 
> > CP components, which is some cases will not be resolvable 
> (noting that 
> > we usually do not peer the MP components for security 
> reasons, and we 
> > But let's assume we have excellent alignment of all the DP/CP 
> > components in 2 same-mode technologies such that we can 
> interwork them 
> > as peers.  A key question we should now pose is 'what is 
> the DP client 
> > component that is passed transparently between the 2 network 
> > partitions?'
> > 
> > moment...if this is the case then the ONLY practical way of dealing 
> > with this is to terminate all DP/CP/MP components of each of the 
> > server layer partitions at the interworking function.  In 
> other words 
> > we have the classical client/server layer network relationship case 
> > when we are NOT at the top-of-stack.  And of course this is what we 
> > see in practice, eg if I want to build an IP network then I 
> can choose 
> > to support the link connections in that IP layer network using 
> > SDH_VC4, PDH_E1, ATM, Ethernet, etc server layer network 
> connections 
> > (ie end-end in the server
> > So folks need think very carefully about what they really mean when 
> > they advocate 'peer interworking' of different or even the 
> same mode 
> > technologies.
> > 
> > <= End Aside
> > 
> > Having dispensed with the argument for TCM between 
> different parties 
> > if we are NOT in a top-of-stack public network service 
> case, let's now 
> > have look at some of it's other consequences.
> > 
> > A network (any mode/technology) has a set of fixed access points 
> > (let's put mobile networks to one side here). Communication takes 
> > place between such access points.  To get between 2 access points A 
> > and B say we require to calculate a route in a graph of 
> nodes and link 
> > connections.
> > In co mode networks we create a connection (which MUST have the 
> > property of single source if we want to also define resource 
> > determinism) and this persists for the lifetime of a 
> communication, ie 
> > all traffic units from A to B always follow the same path.  
> We don't 
> > create connections in a cl-ps technology and traffic units 
> from A to B 
> > can follow different paths, in principle on a traffic unit 
> by traffic 
> > unit basis.
> > 
> > In all cases we can quite sensibly define MEPs for these A/B 
> > end-points and monitor this for connectivity/performance.  But what 
> > about all the intermediate points the path from A to B goes through?
> > 
> > sublayer segments of the path and create MEPs here.  (And of course 
> > this would be a single party doing this in a non 
> top-of-stack case for 
> > the reasons I outlined earlier wrt why we usually don't 
> want/need-to 
> > fine.  Now what happens if we want to change the route of the path 
> > from A to B, eg planned works or a failure/restoration event?
> > Well, A and B
> > ones...assuming we *know* where the new path is going to be and we 
> > have all the CP/MP/OSS tools to do this.
> > 
> > of unreliability) but it is doable I suppose.  We will have some 
> > rather tricky issues wrt accurate performance metric 
> accounting across 
> > such changes at the nested intermediate points.
> > 
> > there.  But we now have the question 'at what holding time 
> would one 
> > not consider it worth the bother/cost of 
> configuring/deconfiguring all 
> > the intermediate points?'.
> > 
> > Now consider the cl-ps mode case.  Here the theoretical 
> holding time 
> > is a rather small single traffic unit....and we also will 
> not usually 
> > know where the traffic will be directed, eg post failures.  Hmmm, 
> > seems to be a real problem.  Well, we could create a set of 
> > pinch-points in the network topology (essentially reduce the graph 
> > connectivity to 1 here) so that the nested intermediate points must 
> > persist across changes in routing.  But this is hardly a 
> good idea as 
> > we are now penalising our ability to provide resilience 
> just so we can 
> > watch these TCM points do their thing.
> > 
> > We might, alternatively, overlay a fixed set of nested TCM 
> levels in 
> > the cl-ps network and pretend it's a co mode network...essentially 
> > what is in Y.1731.  I suppose at this point we also have to observe 
> > that Ethernet is unusual as a cl-ps mode technology as it 
> always must 
> > force a connectivity of one per VLAN...so it is most tempting to 
> > believe TCM is viable here, just like the long-holding co mode case 
> > which I started with.  But this thinking cannot be applied to cl-ps 
> > mode networks which have a directed routing function like 
> IP and can 
> > have a rich/arbitrary meshing with traffic units taking any 
> route they 
> > like (in
> > principle) and
> > Think I've said enough here for folks to mull over....but 
> I'll leave 
> > you with 2 final thoughts:
> > > Cc: Harrison,N,Neil,CXM R; [email-masked]; Jeremy Brayley; 'Danny 
> > > McPherson'; Alik Shimelmits; [email-masked]
> > > However, the latest available version of GR-253 I could 
> put my hands 
> > > on does not specify ANY TCM-related requirements that the 
> SONET NEs 
> > > must match (just mentions  that this functionality has been 
> > > defined).
> > > 
> > > In a more generic way, I think that there are two 
> mindsets when it 
> > > comes to defining the  OAM functions:
> > > 
> > > Approach 2: "What is the minimum that the operators 
> really cannot do 
> > > without?"
> > > 
> augmented 
> > > with some extension potential, while Approach 1 may easily result 
> > > not just in "bloated" (I quote Neil)  specs but also in more 
> > > expensive equipment.
> > > 
> > > My 2c.
> > >         Sasha
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >