Subject: [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document

From: Loa Andersson <[email-masked]>
Date: Thu, 17 Dec 2009 05:36:04 +0100

All,

this is to start a two week poll on making

http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt

an MPLS working group document.

Send a mail to the [email-masked] mailing list,
indicating "yes/support" or "no/do not support".

Comments on the content of the draft should be sent to the same
mailing list with a different subject line.

The poll ends Friday 15 Jan, 2010.

/Loa
-- 

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

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 17 Dec 2009 00:16:30 -0600

yes/support. 

Thanks

Regards... Zafar  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Wednesday, December 16, 2009 11:36 PM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls-tp] Poll om making 
> http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a 
> working group document
> 
> All,
> 
> Send a mail to the [email-masked] mailing list, indicating 
> "yes/support" or "no/do not support".
> 
> Comments on the content of the draft should be sent to the 
> same mailing list with a different subject line.
> 
>                                               +46 767 72 92 
> 13 _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 17 Dec 2009 08:42:54 +0100

No/do not support.

Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Loa Andersson
Sent: donderdag 17 december 2009 5:36
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [mpls-tp] Poll om making
http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group
document

All,

Send a mail to the [email-masked] mailing list, indicating "yes/support"
or "no/do not support".

Comments on the content of the draft should be sent to the same mailing list
with a different subject line.

/Loa
-- 

_______________________________________________

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 17 Dec 2009 08:45:15 +0100

Some comments on the content of this draft:

In section 2.1 it is stated: 
"  <..>
   For example an AIS message may be sent during a protection switching
   event and would cease being sent if the protection switch was
   successful in restoring the link.

   Its primary purpose is to suppress alarms in the MPLS-TP layer
   network above the level at which the defect occurs.  The AIS message
   MAY be used to trigger recovery mechanisms.  It should be noted that
   such use would be subject to false positives, e.g. unnecessary
   protection switching events in the client layer."

It is not correct to state that AIS sending is stopped if the protection
switch was succesful. The reason is that the AIS insertion is done by a MEP
Sink function that is upstream of the protection switch selector process,
and this MEP Sink function is as such unaware of the presence of a
protection switch process and of the state of the protection switch process.

AIS in packet transport networks must **not** used to trigger recovery
mechanisms. Reason is that AIS OAM messages in packet transport network are
to be generated within 1 second after the detection of the signal fail type
defect detection and be generated with a periodicity of 1 second. These
times are much too long to trigger any recovery mechanism.

The 1 second time requirement to generate the first AIS message is derived
from the 2.5 +/- 0.5 second fault cause to failure integration timer as
specified in G.7710. Generation of the first AIS message within a period of
1 second will leave enough time to reach the downstream MEP Sink function
and suppress the fault cause that report the interruption of the connection.

Protection switching in packet transport networks is triggered by e.g. loss
of continuity and misconnection defects.

In section 2.2 it is stated:
"  The LDI message is generated in response to detecting a fatal failure
   in the server layer.  The LDI message MUST NOT be sent until the
   defect has been determined to be fatal.  For example during a
   protection switching event LDI messages are not sent.  However if the
   protection switch was unsuccessful in restoring the link within the
   expected repair time, an LDI message MUST be sent."
and in section 2.1 it is stated:
"  The MPLS-TP Alarm Indication Signal (AIS) message is generated in
   response to detecting defects in the server layer.  The AIS message
   SHOULD be sent as soon is the condition is detected, that is before
   any determination has been made as to whether the condition is fatal."

This draft suggest that it is possible for a MEP Sink function to determine
if the fault is *fatal* or *not fatal*. This is not possible for a MEP Sink
function. The reason is that a MEP Sink function has no knowledge of the
presence or state of a protection switch process associated with the
connection. E.g. the protection switch process may be in a downstream node.

It is also not necessary to make AIS generation conditional on e.g.
protection switch actions. Reason is that a protection switch process will
select traffic from either a working connection input port, or a protection
connection input port. Any traffic present on the not selected input port
will drop at this input port and not be forwarded to the protection switch
process output port. At the output port AIS messages will be present as long
as the protection switch process selects its traffic from the failed
connection; once the protection switch process selects its traffic from the
non-failed connection AIS messages will not longer be forwarded to the
output port.

This draft should as such not become a WG document.

Regards,
Maarten

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

All,

/Loa
--

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 17 Dec 2009 10:08:50 +0000

**
yes/support

Stewart

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 17 Dec 2009 05:38:14 -0800

yes/support

Regards,
Greg

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 17 Dec 2009 05:49:22 -0800

Support 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Maarten Vissers
> Sent: Wednesday, December 16, 2009 11:43 PM
> To: 'Loa Andersson'; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [PWE3] [mpls-tp] Poll om 
> makinghttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a 
> working groupdocument
> 
> No/do not support.
> 
> Maarten 
> 
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 17 Dec 2009 08:33:42 -0600

yes/support. 
Luyuan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Loa Andersson
Sent: 16 December 2009 23:36
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [mpls-tp] Poll om making
http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group
document

All,

Comments on the content of the draft should be sent to the same mailing
list with a different subject line.

/Loa
--

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 17 Dec 2009 09:11:56 -0600

I support the draft to become a WG document, but I also support Maarten's comments raised in his other email. These comments should be addressed after the draft has become a WG draft.

Regards,
Kam
 
New email address: 
[email-masked], effective 1 November 2009 

> Of Drake, John E
> Sent: Thursday, December 17, 2009 8:49 AM
> To: Maarten Vissers; 'Loa Andersson'; [email-masked]; [email-masked];
> Subject: Re: [mpls-tp] [PWE3] Poll om makinghttp://www.ietf.org/id/draft-
> sfv-mpls-tp-fault-01.txt a working groupdocument
> 
> Support
>

---

From: "Rolf Winter" <[email-masked]>
Date: Thu, 17 Dec 2009 17:14:07 +0100

I second Kam on this.

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> Behalf Of Lam, Hing-Kam (Kam)
> Sent: Donnerstag, 17. Dezember 2009 16:12
> To: [email-masked]
> Subject: Re: [mpls-tp] [PWE3] Poll om
> makinghttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working
> groupdocument
> 
> I support the draft to become a WG document, but I also support
> Maarten's comments raised in his other email. These comments should be
> addressed after the draft has become a WG draft.
> 
> Regards,
> Kam
> 
> New email address:
> Behalf

---

From: [email-masked]
Date: Fri, 18 Dec 2009 09:43:08 +0800

I think that Maarten's comments will be good. I hope the authors of the 
draft can clarify the problems according to these comments.
IMO, only all understand  the answers to these problems. then continue to 
next steps for this draft. it is the best way.

best  regards
liu

Maarten Vissers <[email-masked]> 
发件人:  [email-masked]
2009-12-17 15:45

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

主题
[mpls-tp] Comment on http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt

It is not correct to state that AIS sending is stopped if the protection
switch was succesful. The reason is that the AIS insertion is done by a 
MEP
Sink function that is upstream of the protection switch selector process,
and this MEP Sink function is as such unaware of the presence of a
protection switch process and of the state of the protection switch 
process.

AIS in packet transport networks must **not** used to trigger recovery
mechanisms. Reason is that AIS OAM messages in packet transport network 
are
to be generated within 1 second after the detection of the signal fail 
type
defect detection and be generated with a periodicity of 1 second. These
times are much too long to trigger any recovery mechanism.

The 1 second time requirement to generate the first AIS message is derived
from the 2.5 +/- 0.5 second fault cause to failure integration timer as
specified in G.7710. Generation of the first AIS message within a period 
of
1 second will leave enough time to reach the downstream MEP Sink function
and suppress the fault cause that report the interruption of the 
connection.

Protection switching in packet transport networks is triggered by e.g. 
loss
of continuity and misconnection defects.

This draft suggest that it is possible for a MEP Sink function to 
determine
if the fault is *fatal* or *not fatal*. This is not possible for a MEP 
Sink
function. The reason is that a MEP Sink function has no knowledge of the
presence or state of a protection switch process associated with the
connection. E.g. the protection switch process may be in a downstream 
node.

It is also not necessary to make AIS generation conditional on e.g.
protection switch actions. Reason is that a protection switch process will
select traffic from either a working connection input port, or a 
protection
connection input port. Any traffic present on the not selected input port
will drop at this input port and not be forwarded to the protection switch
process output port. At the output port AIS messages will be present as 
long
as the protection switch process selects its traffic from the failed
connection; once the protection switch process selects its traffic from 
the
non-failed connection AIS messages will not longer be forwarded to the
output port.

Regards,
Maarten

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

All,

list

/Loa
-- 

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

---

From: David Sinicrope <[email-masked]>
Date: Fri, 18 Dec 2009 04:02:36 -0500

Support

On 12/16/09 11:36 PM, "Loa Andersson" <[email-masked]> wrote:

All,

/Loa
--

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 18 Dec 2009 12:29:50 +0100

I would like to raise three additional issues in this draft.

1) in section 3 it is stated "The FM Channel uses ACH TLVs and MUST include
the ACH TLV header." and "The ACH TLVs may include (but are not limited to)
IF-ID, Global-ID, and ICC." AIS and LCK OAM messages should not carry any
identifiers, as such identifiers are not read by the receiving MEP. Those
identifiers are not providing any useful information to network management
or detector circuits. Addition of such identifiers to the AIS and LCK frames
adds unnecessary complexities to the designs.

2) In section 4 it is stated "R-flag   The R-flag is normally set to zero.
A setting of one indicates the removal of a previously sent FM condition."
This R-flag is not a helpful feature in AIS and LCK messages. Addition of
such flag only increases complexity of the solution and designs. It is a
classical item, discussed in previous OAM developments as well. The idea is
that the receiver can be explicitly informed about the end of the AIS or LCK
condition. Unfortunately it is necessary to take into account that a packet
may be dropped due to congestion or bit errors. As such, the AIS and LCK
detector circuits in the MEP Sink fucntions must be able to clear the AIS
and LCK defects also when such packet with R-flag was lost (which is
foreseen in the specification in section 5.3). It is therefore less complex
to have the absence of three AIS or LCK packets being used as clearing
condition for the AIS and LCK defects.

3) In section 4 it is stated "Refresh Timer   The maximum time between
successive FM messages specified in seconds.  The range is 1 to 65535.  The
value 0 is not permitted. The default value is 60." The default AIS and LCK
repetition period is generically 1-second, not 60-seconds. There is no need
for a range of AIS and LCK repetition periods. The first AIS packet for each
LSP/PW impacted by the fault has to be generated within 1 second after a
signal fail type defect is detected and the next one has to be generated
1-second later. This 1 second period is necessary in order to prevent that
downstream the alarms are raised (which happens after 2.5 +/- 0.5 seconds).
If the first AIS packet was lost (due to congestion or bit errors) then
there is a second AIS packet that will be received by the MEP Sink fucntion
before the 2.5 +/- 0.5 second fault cause to failure filter will expire.
Either the first or second AIS packet will clear the fault cause and prevent
the alarm from being raised.

MPLS-TP AIS and LCK OAM packets should be very simple OAM packets including
only a Version number and OAM Type (MsgType or OpCode). AIS and LCK OAM
packets should be inserted within 1 second after the condition to generate
those packets became active and these OAM packets must be send with a 1
second repetition rate.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: donderdag 17 december 2009 8:45
To: 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [mpls-tp] Comment
onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt

Regards,
Maarten

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

All,

/Loa
--

---

From: <[email-masked]>
Date: Sat, 19 Dec 2009 13:54:38 -0000

I also have some comments on this draft.  

Major Arch point:
----------------
The key issue here is that the co-ps mode should not be using AIS.  It
is a mistake to try and copy the co-cs mode.

In the co-cs mode labelling and resource allocation are fixed and
intrinsically bound together (this is a consequence of using regular
fixed-size time-slices of resource).  When such a co-cs mode signal
'dies' one simply has to replace it with something (ie a 'resource hole'
must be filled with something)...and if we delve back into the history
of early PDH path layer networks one will find a binary all 1s signal
was the natural traffic signal replacement.

In the cl-ps mode we do not have a connection and we thus do not have an
a priori fixed client/server relationship...which as an aside is also
why we must have a PID label in all cl-ps mode traffic units but we do
not require a PID function in co-cs/ps mode traffic units when carrying
a single client.  However, the key point here is that AIS makes no sense
whatsoever for the cl-ps mode.  But of course we already know that...if
it were not true IP would have adopted it years ago.

We can do everything we need using CV for defect detection in the co-ps
mode (and where BDI is useful for single ended monitoring and effecting
some simple protection-switching cases).  We do not require AIS in the
co-ps mode.  It is just something else that must be consciously
generated and thus can go wrong.

I do not make the above observation lightly.  We have had much internal
discussion on this topic several years ago (I started off in favour of
co-ps mode AIS) before reaching a somewhat counter-intuitive conclusion
that AIS should not be used in co-ps mode layer networks.  We should not
therefore make this mistake in MPLS-TP IMO...but also see next point.

Some related observations:
-------------------------
AIS in the co-cs mode is a *replacement for the DP traffic signal*.  If
one really wanted to emulate the co-cs mode here, the co-ps mode AIS
must look as identical as possible to the normal co-ps mode DP traffic
unit.  In the draft the AIS is using a reserved label (the GAL) that
does not normally appear in the *traffic DP*.  In fact we should have
only allowed the GAL to be used for logically OOB CP/MP protocols and
not any OAM DP functions.

There are some related issues here that I will not expand on but simply
mention in passing as they are germane to fixing MPLS-TP properly:
-	there should not be a PW layer network above MPLS-TP....PWs are
an artefact of the arch problems of LDP and in MPLS-TP would simply
represent an unnecessary cost
-	there should not be arbitrary sublayering in a co-ps mode
transport network, ie the S-bit issue...all MPLS-TP LSPs should
represent their own layer network.  This (and the prior comment on PWs)
is important looking ahead to getting the key MPLS-TPoverMPLS-TP
client/server relationship correct.
-	the OAM indicate function should be a part of the normal DP
traffic header (and not indicated by adding a further reserved
label...esp one that should only be used with the logically OOB CP/MP
protocols)
-	a co-ps mode network has no need for a TTL function in the child
traffic units of a parent connection.

There is of course still time to get MPLS-TP right in these respects,
however I sadly don't see it happening now....which is why, if I am
honest, I can't get too excited about whether this draft progresses or
not.

regards, Neil

> From: [email-masked] [mailto:[email-masked]] On 
> Sent: 17 December 2009 07:45
> Subject: [mpls] Comment 
> It is not correct to state that AIS sending is stopped if the 
> protection switch was succesful. The reason is that the AIS 
> insertion is done by a MEP Sink function that is upstream of 
> the protection switch selector process, and this MEP Sink 
> function is as such unaware of the presence of a protection 
> switch process and of the state of the protection switch process.
> 
> AIS in packet transport networks must **not** used to trigger 
> recovery mechanisms. Reason is that AIS OAM messages in 
> packet transport network are to be generated within 1 second 
> after the detection of the signal fail type defect detection 
> and be generated with a periodicity of 1 second. These times 
> are much too long to trigger any recovery mechanism.
> 
> The 1 second time requirement to generate the first AIS 
> message is derived from the 2.5 +/- 0.5 second fault cause to 
> failure integration timer as specified in G.7710. Generation 
> of the first AIS message within a period of
> 1 second will leave enough time to reach the downstream MEP 
> Sink function and suppress the fault cause that report the 
> interruption of the connection.
> 
> Protection switching in packet transport networks is 
> triggered by e.g. loss of continuity and misconnection defects.
> 
> This draft suggest that it is possible for a MEP Sink 
> function to determine if the fault is *fatal* or *not fatal*. 
> This is not possible for a MEP Sink function. The reason is 
> that a MEP Sink function has no knowledge of the presence or 
> state of a protection switch process associated with the 
> protection switch actions. Reason is that a protection switch 
> process will select traffic from either a working connection 
> input port, or a protection connection input port. Any 
> traffic present on the not selected input port will drop at 
> this input port and not be forwarded to the protection switch 
> process output port. At the output port AIS messages will be 
> present as long as the protection switch process selects its 
> traffic from the failed connection; once the protection 
> switch process selects its traffic from the non-failed 
> connection AIS messages will not longer be forwarded to the 
> output port.
> 
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 21 Dec 2009 17:46:35 +0100

support, however the comments from Maarten Vissers in message
"Comment on http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt"
have to be addressed.

Regards, Huub.
===================

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

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 21 Dec 2009 17:48:06 +0100

I support the following comments.

Regards, Huub.

=====================