Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

From: Maarten Vissers <[email-masked]>
Date: Thu, 09 Dec 2010 09:46:56 +0100

Andy,

In addition to my response yesterday, see below for some further responses…

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 8 December 2010 13:49
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

Nurit,

I know Neil has replied. I will try and say the same thing in my own words.

The server does not and must not know the nature of the client traffic. If
it does, this creates a dependency between the server layer functionality
and its clients which mean that either (1) all future clients must conform
to the same dependency or (2) the server needs to be changed to accommodate
new clients. Personally, I prefer to take independency as defining of
client/server.

The server can and should know about failures which interrupt or otherwise
affect the transport of the client information across the server network (a
MEP which is part of the termination function). So the server can pass up to
the client layer an alarm condition, however, the server cannot know how to
forward on this information to downstream nodes in the client layer. This is
a truism arising out of the independency between client and server.

However, as Maarten correctly pointed out, an adaptation function can know
this information. The adaptation is not part of the server layer and can be
specific to each client. It is the client layer's "stub" to interface to the
server layer.

[maarten] The adaptation sink functions in the transport network
technologies not only “can know” this information, they actually “do know”
this information. 

Within the TDM world, the destination of each timeslot is *preconfigured* as
an inherent part of the connection set up process and the forwarding of each
timeslot is predetermined by this preconfiguration. As such, each timeslot
does not carry any forwarding information. This means that the adaptation
function can fill each timeslot with the alarm condition (AIS) without any
knowledge of downstream forwarding - the adaptation function has no
dependency on any forwarding information. This makes the implementation of
AIS in TDM simple and highly reliable.

[maarten] Please understand that AIS is not carried per timeslot. AIS is
carried per client signal, and those client signals are carried in one or
more timeslots using justification (either AMP or GMP). This implies in PDH
and OTN that the timeslots carry bits with values of 1 (client signal bits
with AIS) and 0 (stuff bits). In SDH with its synchronous clocks, timeslot
can carry just a stream of 1’s because the justification process is
overruled; i.e. justification control bits (H1H2, V1V2) carry a special
pattern.

[maarten] Please understand that the ‘destination of each timeslot’ is not
preconfigured. What is configured is the mapping of a client signal to one
or more timeslots and the TP ID; i.e. the mapping of a client signal to
specific bits of the resource and the identifier associated with those bits.
In OTN this mapping and identifier information is carried inside the HO OPU
overhead, specifically in the MSI bytes. If the OTN would not have been a
transport network technology, the mapping and identifier information in the
MSI bytes could have been used by the adaptation sink function instead of
the preconfigured information.

The mapping and identifier information carried in the MSI bytes is lost
whenever there is a HO ODU failure.

However, as Neil points out, this is not the case with packets. With
packets, forwarding information is carried in the header of each packet with
downstream forwarding is fundamentally based on this information. This
information is lost whenever there is a server layer failure.  **Therefore
the adaptation function cannot insert the alarm condition without itself
having a prior knowledge of this forwarding information.** This is
fundamentally different to the TDM case and arises from the very definition
of packets.

[maarten] The MSI bytes in the HO OPU carry the mapping information of
client signal bits onto resource bits and the identifier values. The VLAN ID
and LSP/PW Label bits carry the mapping information of client signal bits
onto resource bits and the identifier value. There is no functional
difference as far as I can see. The same type of information is present in
both cases. Only the encoding is different; e.g. the identifiers are: TP ID
ó VLAN ID ó LSP Label ó PW Label.

[maarten] Please note that there are two types of ‘forwarding information’
encoded in VLAN frames and there is one type of ‘forwarding information’
encoded in a LSP or PW packet. 

1)      The 12-bit VLAN ID, the 20-bit LSP Label and the 20-bit PW Label
fields carry their connection identifiers within the scope of their server
trail. 

2)      The MAC DA field carries information which may be associated with
one or more external (VLAN Access Port) or internal (VLAN MEP or MIP) egress
port(s) of the VLAN.

In transport networks the first type of information is preconfigured in the
adaptation source and sink functions, and there is a mapping between this
information and the connection points and flow points.

[maarten] The second type of information is used in RMP and MP2MP VLANs to
optimize the forwarding of frames to the relevant subset of output ports of
the RMP/MP2MP VLAN. This information is not stored/preconfigured in
ETHx/ETH-m_A functions.

So how can this be achieved. There are three alternatives, none attractive.
Nor do I believe there is total clarity between two of these, what is
actually proposed for MPLS-TP.

1) The direct analogy with TDM would be for the adaptation function to
systematically send an AIS packet to every possible label value. Given the
size of the MPLS label space, this is not remotely practical.

[maarten] TDM adaptation functions do not send AIS to every possible
Tributary Port (TP) that could exist on the adaptation function. I.e. the
ODUkP/ODUj-21_A_Sk function only sends ODU-AIS for the active TPs, and it
does **not** send 80 ODU0-AIS, 40 ODU1-AIS, 10 ODU2-AIS, 10 ODU2e-AIS, 3
ODU3-AIS and 80 ODUflex-AIS signals for the possible TPs on an
ODU4P/ODUj-21_A_Sk function.

2) Implement the AIS as an integral and required part of each and every
packet forwarding engine. As the forwarding engine is configured with the
forwarding information as part of any connection set process (signalled or
NMS), this requires no more configuration than the TDM case. However, there
are two immediate drawbacks to this. First, as I'm aware the current
installed based of MPLS switches are neither designed nor configured to
automatically add an AIS packet flow to each configured LSP passing through
an input port to the switch. Moreover, it requires that the forwarding
semantics carry input (server sink) port information.

[maarten] Existing MPLS switches were not designed to support Transport
Profile features in general. A subset of existing MPLS switches will be able
to support all TP features by means of a new software release, other
existing MPLS switches will only be able to support a subset of TP features
with a software update, or will be able to support all TP features but
without meeting the required performance (e..g can do CC/CV but only for 100
LSPs and only 1 CC/CV per LSP per second). T-MPLS switches were designed to
support Transport Profile features, and will be able to support generation
and insertion of AIS packets to each configured LSP/PW passing through the
input port to a switch.

3) Implement the AIS as an additional capability within the adaptation
function. However, this now needs to be configured with the correct
forwarding information (ie a set of active label values). If the AIS is not
an integral part of the connection set up process, this configuration
information will need to be separately calculated and configured (for
example by snooping) which means that the tie back of this information to
the connection set up information can itself now be error/fault prone.
Moreover, errors in the configuration data are unlikely to become apparent
until there is a server layer failure and the AIS insertion is exercised.
This means that inevitably, at the time of a failure downstream cannot have
full confidence in the AIS information. Moreover, some adaptation may not be
configured at all, and so a client path failure with a lack of AIS will be
an especially untrustworthy condition. This is fundamentally different to
the highly reliable AIS of the TDM world.

[maarten] All transport network technology adaptation functions have this as
a default capability. This capability is one of the transport network
characteristics. 

[maarten] As indicated in my response yesterday, packet adaptation functions
have been equipped with an AIS insertion enable/disable capability to
support operators that do not want to use AIS. Operators that do use AIS
will set the AIS insertion to enabled as a client connection independent
default for the adaptation function. I.e. there is no specific control
required during connection set up as such in those networks. It is only
required to configure the matrix connection, and this automatically
instantiates the CP/FP and CSP (client specific process) for this connection
in the adaptation functions on the node’s input and output ports.

In practice, I'm sure we are talking about the third of these, which as I
point out, from the practical operational point of view, is fundamentally
different to TDM AIS as it is trustworthy in the same way. Sometimes,
especially when talking with Maarten, I think he is referring to the second
of these (and I may be wrong), which while operationally more reliable, I
don't think is realistic.

[maarten] I hope I have clarified that AIS is an integral (and not ‘an
additional’) capability in transport network technology adaptation sink
functions. The set up of LSP and PW matrix connections by e.g. NMS will
identify input and output ports and the label values on those ports for this
connection. This information is used within the MPLS-TP switch to configure
the adaptation functions on the input and output ports.  It could be that
some existing MPLS switches can not be upgraded to support this equipment
internal configuration… this equipment will in that case not be able to
support the full set of TP features, and it will be an operators choice to
deploy it within a -TP network or to not deploy it within a -TP network.
Existing T-MPLS switches will be able to support the full set of -TP
features, including this AIS generation/insertion.

Regards,

Maarten

Hope this clarifies.

Andy

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 9 Dec 2010 12:04:54 +0200

Maarten,
One brief comment that you probably have heard quite a few times from me.

You have said in your response to Andy Reid:
The adaptation sink functions in the transport network technologies not only "can know" this information, they actually "do know" this information.
The problem with MPLS-TP is that, as long as its data plane is aligned with that of MPLS (and it is!) its analog of the "adaptation sink function", namely the ILM entry with the "Pop and Loop" action on a specific label do not have this information. I.e., when MPLS pops a label, it can handle both labeled and unlabeled packets that result from this action. When the resulting packet is labeled, handling of the next label does not depend on the previous one.
And of course handling unlabeled packets (IP as an immediate client of an MPLS-TP LSP) is just as possible and, IMHO, just as relevant...

After writing this, I think (and I apologize that I've only noticed it that late), that IP as an MPLS-TP client that does not have any AIS is a great counter-example to AIS into the clients...

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Thursday, December 09, 2010 10:47 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

Andy,

In addition to my response yesterday, see below for some further responses...

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 8 December 2010 13:49
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

Nurit,

The server does not and must not know the nature of the client traffic. If it does, this creates a dependency between the server layer functionality and its clients which mean that either (1) all future clients must conform to the same dependency or (2) the server needs to be changed to accommodate new clients. Personally, I prefer to take independency as defining of client/server.

The server can and should know about failures which interrupt or otherwise affect the transport of the client information across the server network (a MEP which is part of the termination function). So the server can pass up to the client layer an alarm condition, however, the server cannot know how to forward on this information to downstream nodes in the client layer. This is a truism arising out of the independency between client and server.

However, as Maarten correctly pointed out, an adaptation function can know this information. The adaptation is not part of the server layer and can be specific to each client. It is the client layer's "stub" to interface to the server layer.

[maarten] The adaptation sink functions in the transport network technologies not only "can know" this information, they actually "do know" this information.

Within the TDM world, the destination of each timeslot is *preconfigured* as an inherent part of the connection set up process and the forwarding of each timeslot is predetermined by this preconfiguration. As such, each timeslot does not carry any forwarding information. This means that the adaptation function can fill each timeslot with the alarm condition (AIS) without any knowledge of downstream forwarding - the adaptation function has no dependency on any forwarding information. This makes the implementation of AIS in TDM simple and highly reliable.

[maarten] Please understand that AIS is not carried per timeslot. AIS is carried per client signal, and those client signals are carried in one or more timeslots using justification (either AMP or GMP). This implies in PDH and OTN that the timeslots carry bits with values of 1 (client signal bits with AIS) and 0 (stuff bits). In SDH with its synchronous clocks, timeslot can carry just a stream of 1's because the justification process is overruled; i.e. justification control bits (H1H2, V1V2) carry a special pattern.

[maarten] Please understand that the 'destination of each timeslot' is not preconfigured. What is configured is the mapping of a client signal to one or more timeslots and the TP ID; i.e. the mapping of a client signal to specific bits of the resource and the identifier associated with those bits. In OTN this mapping and identifier information is carried inside the HO OPU overhead, specifically in the MSI bytes. If the OTN would not have been a transport network technology, the mapping and identifier information in the MSI bytes could have been used by the adaptation sink function instead of the preconfigured information.
The mapping and identifier information carried in the MSI bytes is lost whenever there is a HO ODU failure.

However, as Neil points out, this is not the case with packets. With packets, forwarding information is carried in the header of each packet with downstream forwarding is fundamentally based on this information. This information is lost whenever there is a server layer failure.  **Therefore the adaptation function cannot insert the alarm condition without itself having a prior knowledge of this forwarding information.** This is fundamentally different to the TDM case and arises from the very definition of packets.

[maarten] The MSI bytes in the HO OPU carry the mapping information of client signal bits onto resource bits and the identifier values. The VLAN ID and LSP/PW Label bits carry the mapping information of client signal bits onto resource bits and the identifier value. There is no functional difference as far as I can see. The same type of information is present in both cases. Only the encoding is different; e.g. the identifiers are: TP ID <=> VLAN ID <=> LSP Label <=> PW Label.

[maarten] Please note that there are two types of 'forwarding information' encoded in VLAN frames and there is one type of 'forwarding information' encoded in a LSP or PW packet.

1)      The 12-bit VLAN ID, the 20-bit LSP Label and the 20-bit PW Label fields carry their connection identifiers within the scope of their server trail.

2)      The MAC DA field carries information which may be associated with one or more external (VLAN Access Port) or internal (VLAN MEP or MIP) egress port(s) of the VLAN.
In transport networks the first type of information is preconfigured in the adaptation source and sink functions, and there is a mapping between this information and the connection points and flow points.

[maarten] The second type of information is used in RMP and MP2MP VLANs to optimize the forwarding of frames to the relevant subset of output ports of the RMP/MP2MP VLAN. This information is not stored/preconfigured in ETHx/ETH-m_A functions.

So how can this be achieved. There are three alternatives, none attractive. Nor do I believe there is total clarity between two of these, what is actually proposed for MPLS-TP.

1) The direct analogy with TDM would be for the adaptation function to systematically send an AIS packet to every possible label value. Given the size of the MPLS label space, this is not remotely practical.

[maarten] TDM adaptation functions do not send AIS to every possible Tributary Port (TP) that could exist on the adaptation function. I.e. the ODUkP/ODUj-21_A_Sk function only sends ODU-AIS for the active TPs, and it does **not** send 80 ODU0-AIS, 40 ODU1-AIS, 10 ODU2-AIS, 10 ODU2e-AIS, 3 ODU3-AIS and 80 ODUflex-AIS signals for the possible TPs on an ODU4P/ODUj-21_A_Sk function.

2) Implement the AIS as an integral and required part of each and every packet forwarding engine. As the forwarding engine is configured with the forwarding information as part of any connection set process (signalled or NMS), this requires no more configuration than the TDM case. However, there are two immediate drawbacks to this. First, as I'm aware the current installed based of MPLS switches are neither designed nor configured to automatically add an AIS packet flow to each configured LSP passing through an input port to the switch. Moreover, it requires that the forwarding semantics carry input (server sink) port information.

[maarten] Existing MPLS switches were not designed to support Transport Profile features in general. A subset of existing MPLS switches will be able to support all TP features by means of a new software release, other existing MPLS switches will only be able to support a subset of TP features with a software update, or will be able to support all TP features but without meeting the required performance (e..g can do CC/CV but only for 100 LSPs and only 1 CC/CV per LSP per second). T-MPLS switches were designed to support Transport Profile features, and will be able to support generation and insertion of AIS packets to each configured LSP/PW passing through the input port to a switch.

3) Implement the AIS as an additional capability within the adaptation function. However, this now needs to be configured with the correct forwarding information (ie a set of active label values). If the AIS is not an integral part of the connection set up process, this configuration information will need to be separately calculated and configured (for example by snooping) which means that the tie back of this information to the connection set up information can itself now be error/fault prone. Moreover, errors in the configuration data are unlikely to become apparent until there is a server layer failure and the AIS insertion is exercised. This means that inevitably, at the time of a failure downstream cannot have full confidence in the AIS information. Moreover, some adaptation may not be configured at all, and so a client path failure with a lack of AIS will be an especially untrustworthy condition. This is fundamentally different to the highly reliable AIS of the TDM world.

[maarten] All transport network technology adaptation functions have this as a default capability. This capability is one of the transport network characteristics.

[maarten] As indicated in my response yesterday, packet adaptation functions have been equipped with an AIS insertion enable/disable capability to support operators that do not want to use AIS. Operators that do use AIS will set the AIS insertion to enabled as a client connection independent default for the adaptation function. I.e. there is no specific control required during connection set up as such in those networks. It is only required to configure the matrix connection, and this automatically instantiates the CP/FP and CSP (client specific process) for this connection in the adaptation functions on the node's input and output ports.

In practice, I'm sure we are talking about the third of these, which as I point out, from the practical operational point of view, is fundamentally different to TDM AIS as it is trustworthy in the same way. Sometimes, especially when talking with Maarten, I think he is referring to the second of these (and I may be wrong), which while operationally more reliable, I don't think is realistic.

[maarten] I hope I have clarified that AIS is an integral (and not 'an additional') capability in transport network technology adaptation sink functions. The set up of LSP and PW matrix connections by e.g. NMS will identify input and output ports and the label values on those ports for this connection. This information is used within the MPLS-TP switch to configure the adaptation functions on the input and output ports.  It could be that some existing MPLS switches can not be upgraded to support this equipment internal configuration... this equipment will in that case not be able to support the full set of TP features, and it will be an operators choice to deploy it within a -TP network or to not deploy it within a -TP network. Existing T-MPLS switches will be able to support the full set of -TP features, including this AIS generation/insertion.

Regards,
Maarten

Hope this clarifies.

Andy

---

From: <[email-masked]>
Date: Thu, 9 Dec 2010 10:38:02 +0000

re-send as plain text and snipped...(too big message received)

________________________________

	From: Harrison,N,Neil,DKQ7 R 
	Sent: 09 December 2010 10:26
	To: 'Alexander Vainshtein'; Maarten Vissers
	Cc: [email-masked]; Reid,ABD,Andy,DEE1 R
	Subject: RE: [mpls-tp] Alarm Reporting (aka AIS)

	The key points are:
	-    AIS is technically not necessary for any pkt-based technologies at all.....we need not consider anything further from this killer observation alone...but if we do, we then observe....
	-    it only has meaning in (i) regular-time slice co-cs mode networks and (ii) only when the client is permanently bound to its server, ie the client never moves...once the client 'clears' or 'moves' wrt to its routing *in the client layer network* (and the server MUST NOT even try and know this!) then the server has no idea who to send the redundant AIS signal to.
	 
	regards, Neil   

________________________________

		From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
		Sent: 09 December 2010 10:05
		To: Maarten Vissers
		Cc: [email-masked]
		Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

		Maarten,

		Regards,

		     Sasha

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 09 Dec 2010 11:50:53 +0100

Hello Neil,

You wrote:

> The key points are:
> - AIS is technically not necessary for any pkt-based
 > technologies at all.....

Then how should we resolve this requirement:
== "A defect event in a given layer network should not
     cause multiple alarm events to be raised, nor cause
     unnecessary corrective actions to be taken in any
     higher level client-layer networks." ==

Regards, Huub.

-- 
*****************************************************************
                          我爱外点一七三一

---

From: <[email-masked]>
Date: Thu, 9 Dec 2010 11:08:51 +0000

Hi Huub,

The trite answer is that whoever wrote, and keeps promulgating, this myth does not properly understand the networking situation....I suspect it is folks purely from the PDH/SDH world and/or those who want to promote TCM.  I can dismiss it immediately by the observation that the Internet and the PSTN (which are fairly major and important networks!) don't rely on this.  If you think about my observations that you snipped here then the logic is irrefutable, ie the client has moved (and the server must not even be party to knowing this)!

Each layer network must be able to look after itself.

Even if we have the restricted case where AIS might have some value (ie co-cs and permanent client/server bindings) we can still observe that CV/BDI alone are all one needs to identify the offending source layer of a problem and deal with most real-world cases of defect detection/handling....with the tapping off of E2E CV/PM flows on the *rare* occasions we might need this for rogue paths....we for sure do not need TCM.  I can take you through the logic if you need me too, but I would hope most folks can figure all this out.

regards, Neil  

> -----Original Message-----
> From: Huub van Helvoort [mailto:[email-masked]] 
> Sent: 09 December 2010 10:51
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 09 Dec 2010 12:18:47 +0100

Hello Neil,

You replied:

> The trite answer is that whoever wrote, and keeps promulgating,
 > this myth does not properly understand the networking situation....

I quoted from recommendation Y.1710.
You may know the editor of this document.

Best regards, Huub.

---

From: <[email-masked]>
Date: Thu, 9 Dec 2010 11:32:32 +0000

LOL....desperation Huub?

If you have followed my posts over many years now you would have noted that I have said many times that I have had to change my mind on the usefulness of AIS in the co-ps mode.  Indeed, in the post I sent Wed 08/12/2010 08:37 I said this:

"I used to think AIS might be useful for the co-ps mode (though it still requires the assumption of permanent client/server binding AND it now requires explicit labelling of every AIS packet => hint not a good idea for reasons that should become clear shortly), but many years ago Andy/I/others discussed this topic in some detail and we reached a unanimous conclusion that AIS is technically completely unnecessary.  Moreover, one is far better off without it for many reasons consequential reasons, eg having to label each traffic unit, something else to go wrong, etc.  All one needs technically in the co-ps mode is the OAM pair CV and BDI functions (however one does these)...this is quite simple to prove.  And this is 'per se'......that is, I am not even considering all the horrors that accompany the TCM ideas.....which BTW is perhaps the self-fulfilling reason to require AIS here (the notification arguments don't hold water as I noted)."
 
regards, Neil 

> Sent: 09 December 2010 11:19

---

From: <[email-masked]>
Date: Thu, 9 Dec 2010 11:51:54 +0000

Sasha,

Fully agree. As you point out AIS with IP as the client is truly meaningless. And as John Drake pointed out earlier, the only currently defined clients for MPLS-TP are IP, MPLS, and PW. And all of these happily look after themselves without AIS.

So we have something which is both untrustworthy and unnecessary. However, the implementation doesn't come for free - we all pay for it anyway. More importantly, the reason always cited for implementing it is 'compatibility with existing transport network operational models'. In these current operational models, AIS is fully trustworthy. So if we follow the logic of it implementation, we will have operational staff trusting something as if it is fully trustworthy when in fact it is not. This is where the true cost of the misguided use of AIS may well lie.

Andy

Andy Reid
Chief Network Services Strategist
BT Innovate

Office: +44 (0)20 8726 3075
Mobile: +44 (0)7917 025451
Fax :       +44 (0)1277 324015
Email:  [email-masked]<mailto:[email-masked]>
WWW:    http://www.bt.com/

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: 09 December 2010 10:05
To: Maarten Vissers
Cc: Reid,ABD,Andy,DEE1 R; [email-masked]
Subject: RE: [mpls-tp] Alarm Reporting (aka AIS)

Maarten,

Regards,
     Sasha

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 09 Dec 2010 13:21:11 +0100

Hi Neil,

> LOL....desperation Huub?

No, looking for consistency between what you say on this list
and what you write in recommendations.

Regards, Huub.

---

From: <[email-masked]>
Date: Thu, 9 Dec 2010 12:40:48 +0000

Huub,

Do you know how old that Rec is?  Do you know that ITU Recs are written by several folks and represent a general view of all particapting parties at that time?  Do you not believe folks can change their minds in the light of improved understanding/knowledge?...a point I have made many times on the lists.  Can you look me in the eye and tell me you have never changed your mind on any technical point in your whole life?

I find it sad you have to resort to these tactics.... 

> Sent: 09 December 2010 12:21

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 09 Dec 2010 13:49:41 +0100

Hi Neil,

You replied:

> Do you know how old that Rec is?

Yes. And there is a more recent one that contains
similar text. So you must have changed your mind
very recently.

> Do you know that ITU  Recs are written by several
 > folks and represent a general view of all
 > particapting parties at that time?

They are approved by consensus.
And because Y.1710 concerns MPLS I would guess that
MPLS experts were present when it was consented.

> Do you not believe folks can change their minds in the
 > light of improved understanding/knowledge?...

Sure, but wouldn't it have been better to document
that change of mind.

Regards, Huub.

---

From: <[email-masked]>
Date: Thu, 9 Dec 2010 12:58:22 +0000

This is my last post on this non-technical stuff....in-line: 

> Sent: 09 December 2010 12:50
> Cc: 
> Yes. And there is a more recent one that contains similar 
> text. So you must have changed your mind very recently.

NH=> Wrong.  I have not attended ITU for about 10 years.  I changed my mind on this topic maybe 6 or 7 years ago after Andy Reid and I discussed this topic in some detail and have been posting this revised view ever since.
>  > folks and represent a general view of all  > particapting 
> parties at that time?
> 
> And because Y.1710 concerns MPLS I would guess that MPLS 
> experts were present when it was consented.
> 
> Sure, but wouldn't it have been better to document that 
> change of mind.

NH=> I have posted the view repeatedly over several years.  I am sorry you never saw them, I am sure other folks have....go ask Malcolm Betts and George Newsome if you don't believe me.

regards, Neil

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 9 Dec 2010 15:54:56 +0100

Huub,
This kind of exchanges is very unpleasant....
We keep hearing Neil's approach on AIS in CO-PS for years..he clearly expressed it many times on the list....It is absolutely not a recent change...
I would also curious to understand what consensus means...does it mean that everyone agreed to the content, that there was no even one objection? 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Thursday, December 09, 2010 2:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

Hi Neil,

Regards, Huub.

-- 
*****************************************************************
                          我爱外点一七三一
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 9 Dec 2010 10:06:11 -0500

Determining consensus is clearly the job of the co-chairs.

	--Tom

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 9 Dec 2010 16:07:55 +0100

Tom,
I was referring to the ITU-T process for consensus...
Huub said that the document was approved by consensus! 
I expect Huub to clarify his point...
Best regards,
Nurit

-----Original Message-----
From: ext Thomas Nadeau [mailto:[email-masked]] 
Sent: Thursday, December 09, 2010 5:06 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Huub van Helvoort; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

	--Tom

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 09 Dec 2010 15:00:32 +0100

Hello Neil

You replied:

> This is my last post on this non-technical stuff.

OK.
Cheers, Huub.

---

From: [email-masked]
Date: Fri, 10 Dec 2010 08:23:15 +0800

Huub,

I think we need to listen to the views of Neil on AIS.

This is just a purely technical discussion, isn't it?

Best regards,
steven

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]> 
发件人:  [email-masked]
2010-12-09 22:54

收件人
"ext Huub van Helvoort" <[email-masked]>, <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] Alarm Reporting (aka AIS)

Huub,
This kind of exchanges is very unpleasant....
We keep hearing Neil's approach on AIS in CO-PS for years..he clearly 
expressed it many times on the list....It is absolutely not a recent 
change...
I would also curious to understand what consensus means...does it mean 
that everyone agreed to the content, that there was no even one objection? 

Best regards,
Nurit

-----Original Message-----
Of ext Huub van Helvoort

Hi Neil,

Regards, Huub.

--------------------------------------------------------
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: Huub van Helvoort <[email-masked]>
Date: Mon, 13 Dec 2010 11:21:17 +0100

Hello Steven,

> This is just a purely technical discussion, isn't it?

Yes it is, I am *not* trying to shoot the messenger.

My concern is that we have a requirement in RFC5860.
A solution (for AIS) is provided in draft-ietf-mpls-tp-fault.

How will the current discussion affect the progress of this
draft?

Regards, Huub.

---

From: <[email-masked]>
Date: Mon, 13 Dec 2010 14:28:45 +0000

Huub wrote 13 December 2010 10:21

> How will the current discussion affect the progress of this draft?

NH=> I guess a key issue here is trying to figure out which, if any, operators still want AIS.  Perhaps those operators did not previously understand that:
-	is it a redundant technical function (for reasons I have explained previously), and 
-	it is a potential source of further problems in itself, as OAM messages have to be constructed/configured (the always-on defect detection needs to be as simple/sparse as possible since it must be significantly more reliable than the network it is monitoring, and thus all unnecessary sources of defects/configuration-errors should be minimised).

Perhaps those operators who may have originally supported the requirement for AIS in packet-switched networks did not properly understood these issues before?

In any case, it is important that for those operators who have properly understood what AIS is to be able to have this function disabled in their networks.

regards, Neil

---

From: John E Drake <[email-masked]>
Date: Mon, 13 Dec 2010 08:33:34 -0800

Huub,

A bis update to the RFC, indicating that upon further refection the requirement was ill-considered, can always be issued.

Thanks,

John 

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, December 13, 2010 6:29 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] 答复: Re: Alarm Reporting (aka AIS)
> 
> NH=> I guess a key issue here is trying to figure out which, if any,
> operators still want AIS.  Perhaps those operators did not previously
> understand that:
> -	it is a potential source of further problems in itself, as OAM
> messages have to be constructed/configured (the always-on defect
> detection needs to be as simple/sparse as possible since it must be
> significantly more reliable than the network it is monitoring, and thus
> all unnecessary sources of defects/configuration-errors should be
> minimised).
> 
> Perhaps those operators who may have originally supported the
> requirement for AIS in packet-switched networks did not properly
> understood these issues before?
> 
> In any case, it is important that for those operators who have properly
> understood what AIS is to be able to have this function disabled in
> their networks.
> 
> regards, Neil
> 
> >
> > Regards, Huub.
> >

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 13 Dec 2010 11:12:03 -0800

+1

2010/12/13 John E Drake <[email-masked]>

> Huub,
>
> A bis update to the RFC, indicating that upon further refection the
> requirement was ill-considered, can always be issued.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>

---

From: John E Drake <[email-masked]>
Date: Mon, 13 Dec 2010 12:35:40 -0800

And, as Maarten pointed out, its absence would align us with the IEEE

Sent from my iPhone

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, December 13, 2010 11:12 AM
To: John E Drake
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] 答复: Re: Alarm Reporting (aka AIS)

+1
2010/12/13 John E Drake <[email-masked]<mailto:[email-masked]>>
Huub,

Thanks,

John

Sent from my iPhone

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp