Subject: [mpls-tp] Proposed liaison to ITU-T on G.8110

From: Stewart Bryant <[email-masked]>
Date: Mon, 28 Jun 2010 18:42:27 +0100

Several people have pointed out a discrepancy in the model for MPLS as 
documented in G.8110. Since this formal model plays a major role in the  
ITU-T MPLS-TP G.8110.1 specification, the error should to be corrected 
before publication.

I therefore propose that we send the following liaison to the ITU-T.

- Stewart

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

To: ITU-T WP3/15
From: IETF

Dear Dr. Trowbridge,

We note that G.8110 is referenced as a normative reference from the 
draft text of the revision of G.8110.1. We also note that G.8110 is
now five years old, and has received no contributions for update over 
that period. G.8110 has been described as "not covering all of MPLS and 
certainly not what has happened in the last five years."

We believe that G.8110.1 should document MPLS-TP accurately. It is 
important, therefore, that where the model for MPLS-TP differs from that 
described in G.8110, the correct model be developed and documented in 
G.8110.1.

We would like to draw your attention in specifically to Section 6.2.2 of 
G.8110 (and, in particular, Figures 1 and 2) that says that the 
Time-To-Live (TTL) field of an MPLS header is part of the Characteristic 
Information (CI) of an MPLS_CI traffic unit. We note that according to 
G.805, the CI is supposed to be delivered end-to-end between MPLS APs 
without modification or inspection. But the function of a TTL in an 
MPLS-TP network is to be decremented at each hop along the path, and to 
be inspected at each hop and tested against zero. Thus, in the model for 
MPLS-TP, the TTL should not form part of the CI.

We request that G.8110.1 be updated to include this revision to the 
model. This might most easily be achieved by augmenting the references 
to G.8110 with updated figures based on those in G.8110 along with 
appropriate text explaining the differences in the model such that 
G.8110.1 correctly captures the model for MPLS-TP.

==========

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Mon, 28 Jun 2010 14:35:47 -0500

Hi Stewart,

I'd suggest addressing the liaison to Malcolm Betts, since any work on the modeling would take place in Q12/15 (and could be handled, as needed, during the October Q12/15 meeting in Shanghai).

Cheers,
Eve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, June 28, 2010 1:42 PM
To: [email-masked]
Subject: [mpls-tp] Proposed liaison to ITU-T on G.8110

- Stewart

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

To: ITU-T WP3/15
From: IETF

Dear Dr. Trowbridge,

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 28 Jun 2010 17:20:43 -0400

Stewart,

That seems like a very reasonable liaison.

Cheers,
Andy

On Mon, Jun 28, 2010 at 1:42 PM, Stewart Bryant <[email-masked]> wrote:
> We note that G.8110 is referenced as a normative reference from the draft
> text of the revision of G.8110.1. We also note that G.8110 is
> now five years old, and has received no contributions for update over that
> period. G.8110 has been described as "not covering all of MPLS and certainly
> not what has happened in the last five years."
>
> G.8110 (and, in particular, Figures 1 and 2) that says that the Time-To-Live
> (TTL) field of an MPLS header is part of the Characteristic Information (CI)
> of an MPLS_CI traffic unit. We note that according to G.805, the CI is
> supposed to be delivered end-to-end between MPLS APs without modification or
> inspection. But the function of a TTL in an MPLS-TP network is to be
> decremented at each hop along the path, and to be inspected at each hop and
> tested against zero. Thus, in the model for MPLS-TP, the TTL should not form
> part of the CI.
>
> We request that G.8110.1 be updated to include this revision to the model.
> This might most easily be achieved by augmenting the references to G.8110
> with updated figures based on those in G.8110 along with appropriate text
> explaining the differences in the model such that G.8110.1 correctly
> captures the model for MPLS-TP.
>
> ==========

---

From: David Sinicrope <[email-masked]>
Date: Mon, 28 Jun 2010 17:50:05 -0400

Agreed.
Dave

On 6/28/10 5:20 PM, "Andrew G. Malis" <[email-masked]> wrote:

Stewart,

Cheers,
Andy

---

From: David Allan I <[email-masked]>
Date: Mon, 28 Jun 2010 19:46:04 -0400

Support...

D 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, June 28, 2010 1:42 PM
To: [email-masked]
Subject: [mpls-tp] Proposed liaison to ITU-T on G.8110

Several people have pointed out a discrepancy in the model for MPLS as documented in G.8110. Since this formal model plays a major role in the ITU-T MPLS-TP G.8110.1 specification, the error should to be corrected before publication.

- Stewart

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

To: ITU-T WP3/15
From: IETF

Dear Dr. Trowbridge,

We note that G.8110 is referenced as a normative reference from the draft text of the revision of G.8110.1. We also note that G.8110 is now five years old, and has received no contributions for update over that period. G.8110 has been described as "not covering all of MPLS and certainly not what has happened in the last five years."

We believe that G.8110.1 should document MPLS-TP accurately. It is important, therefore, that where the model for MPLS-TP differs from that described in G.8110, the correct model be developed and documented in G.8110.1.

We would like to draw your attention in specifically to Section 6.2.2 of G.8110 (and, in particular, Figures 1 and 2) that says that the Time-To-Live (TTL) field of an MPLS header is part of the Characteristic Information (CI) of an MPLS_CI traffic unit. We note that according to G.805, the CI is supposed to be delivered end-to-end between MPLS APs without modification or inspection. But the function of a TTL in an MPLS-TP network is to be decremented at each hop along the path, and to be inspected at each hop and tested against zero. Thus, in the model for MPLS-TP, the TTL should not form part of the CI.

We request that G.8110.1 be updated to include this revision to the model. This might most easily be achieved by augmenting the references to G.8110 with updated figures based on those in G.8110 along with appropriate text explaining the differences in the model such that
G.8110.1 correctly captures the model for MPLS-TP.

==========

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 29 Jun 2010 07:38:14 +0200

Hi,

The liaison sounds very good.

Just one editorial comment - There is a superfluous "in" in the first
sentence of the third paragraph.  I assume that it should read - "We
would like to draw your attention specifically to ..."

BR,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Stewart Bryant
Sent: Monday, June 28, 2010 20:42
To: [email-masked]
Subject: [mpls-tp] Proposed liaison to ITU-T on G.8110

- Stewart

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

To: ITU-T WP3/15
From: IETF

Dear Dr. Trowbridge,

==========

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Tue, 29 Jun 2010 09:04:21 +0200

Stewart,

could you please explain why the TTL processing in MPLS-TP is different from TTL processing in MPLS?

Alternatively, what changes in MPLS TTL processing have been defined in the last 5 years that caused the TTL processing model of G.8110 to be no longer accurate?

Thanks, Italo 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: lunedì 28 giugno 2010 19.42
> To: [email-masked]
> Several people have pointed out a discrepancy in the model 
> for MPLS as documented in G.8110. Since this formal model 
> plays a major role in the ITU-T MPLS-TP G.8110.1 
> specification, the error should to be corrected before publication.
> 
> We note that G.8110 is referenced as a normative reference 
> from the draft text of the revision of G.8110.1. We also note 
> that G.8110 is now five years old, and has received no 
> contributions for update over that period. G.8110 has been 
> described as "not covering all of MPLS and certainly not what 
> has happened in the last five years."
> 
> We believe that G.8110.1 should document MPLS-TP accurately. 
> It is important, therefore, that where the model for MPLS-TP 
> differs from that described in G.8110, the correct model be 
> developed and documented in G.8110.1.
> 
> We would like to draw your attention in specifically to 
> Section 6.2.2 of G.8110 (and, in particular, Figures 1 and 2) 
> that says that the Time-To-Live (TTL) field of an MPLS header 
> is part of the Characteristic Information (CI) of an MPLS_CI 
> traffic unit. We note that according to G.805, the CI is 
> supposed to be delivered end-to-end between MPLS APs without 
> modification or inspection. But the function of a TTL in an 
> MPLS-TP network is to be decremented at each hop along the 
> path, and to be inspected at each hop and tested against 
> zero. Thus, in the model for MPLS-TP, the TTL should not form 
> part of the CI.
> 
> We request that G.8110.1 be updated to include this revision 
> to the model. This might most easily be achieved by 
> augmenting the references to G.8110 with updated figures 
> based on those in G.8110 along with appropriate text 
> explaining the differences in the model such that

---

From: <[email-masked]>
Date: Tue, 29 Jun 2010 08:37:07 +0100

Stewart,
Whilst I don't agree with your proposed liaison I'd like to make a suggestion. Your statement that " We note that according to G.805, the CI is 
supposed to be delivered end-to-end between MPLS APs without modification or inspection" is incorrect by definition. CI information is transferred between Termination Connection Points (TCPs) and not between AP's. Indeed the point of the source termination function is to add information to adapted information which traverses the AP and thus to generate CI and the corresponding sink processes information.

This is quite clear from G.805 and is also well described in Sexton and Reid. I would therefore suggest you correct your liaison.

Regarding the model for TTL, I am sure that Q12 will be happy to explain the reasoning behind the way it was constructed and how the TTL value is decremented on a per hop basis. But perhaps it might be more appropriate to ask for an explanation of how the model works before assuming that it is wrong.

Best regards
Alan

> We note that according to G.805, the CI is 
> modification or inspection

---

From: <[email-masked]>
Date: Tue, 29 Jun 2010 11:03:15 +0100

I agree with Alan that one should ask Q12 why they used a specific approach for the modelling of TTL in MPLS.  However, one has to observe that in a co-ps mode transport network based on proper connections then a TTL function is unnecessary....so asking whether we are accurately modelling something that is just plain wrong is a rather strange thing to focus on (and I'll wager this is why it has a strange handling model in G.8110).

Perhaps Stewart's mail is the catalyst to ask the question why we simply don't null the TLL function in MPLS-TP?

Aside=> We can't appeal to an argument that 'it's a profile of MPLS' because MPLS-TP is creating a new layer co-ps mode network technology since it adds new functional behaviours not found in any existing spin of MPLS (eg logically OOB CP, new addressing types, new OAM) in addition to reusing as much of the existing MPLS specification as it can......even inappropriate bits unfortunately....which is the case we have here.

regards, Neil

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 29 June 2010 08:37
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Proposed liaison to ITU-T on G.8110
> 
> Stewart,
> Whilst I don't agree with your proposed liaison I'd like to 
> make a suggestion. Your statement that " We note that 
> according to G.805, the CI is supposed to be delivered 
> end-to-end between MPLS APs without modification or 
> inspection" is incorrect by definition. CI information is 
> transferred between Termination Connection Points (TCPs) and 
> not between AP's. Indeed the point of the source termination 
> function is to add information to adapted information which 
> traverses the AP and thus to generate CI and the 
> corresponding sink processes information.
> 
> This is quite clear from G.805 and is also well described in 
> Sexton and Reid. I would therefore suggest you correct your liaison.
> 
> Regarding the model for TTL, I am sure that Q12 will be happy 
> to explain the reasoning behind the way it was constructed 
> and how the TTL value is decremented on a per hop basis. But 
> perhaps it might be more appropriate to ask for an 
> explanation of how the model works before assuming that it is wrong.
> 
> Best regards
> Alan
> 
> > We note that according to G.805, the CI is supposed to be delivered 
> > end-to-end between MPLS APs without modification or 
> inspection Several 
> > people have pointed out a discrepancy in the model for MPLS as 
> > documented in G.8110. Since this formal model plays a major role in 
> > the ITU-T MPLS-TP G.8110.1 specification, the error should to be 
> > corrected before publication.
> > 
> > that period. G.8110 has been described as "not covering all of MPLS 
> > and certainly not what has happened in the last five years."
> > 
> > It is important, therefore, that where the model for 
> MPLS-TP differs 
> > from that described in G.8110, the correct model be developed and 
> > documented in G.8110.1.
> > 
> Section 6.2.2 
> > of G.8110 (and, in particular, Figures 1 and 2) that says that the 
> > Time-To-Live (TTL) field of an MPLS header is part of the 
> > Characteristic Information (CI) of an MPLS_CI traffic unit. We note 
> > that according to G.805, the CI is supposed to be delivered 
> end-to-end 
> > between MPLS APs without modification or inspection. But 
> the function 
> > of a TTL in an MPLS-TP network is to be decremented at each 
> hop along 
> > the path, and to be inspected at each hop and tested against zero. 
> > Thus, in the model for MPLS-TP, the TTL should not form part of the 
> > CI.
> >

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 29 Jun 2010 12:09:26 +0200

Hi,

It is correct that the CI is transferred on a "network connection" which is formed by a series of contiguous "link connections" and/or "subnetwork connections" between "termination connection points". We should fix the proposed liaison accordingly! 

Still the concern is valid. 

G.805 refers to the generation (at the source), transport and termination (at the sink) of CI (in the context of a layer network), and also to the interworking of CI of one layer network with the CI another layer, but not to the processing of the CI at each transport entity or port along the network connection. 

Therefore I support the liaison with the correction of TCPs and not APs.

I think also that the fact that G.8110 (which is used as a normative reference) has not been updated since 2005, raises more concerns. MPLS was worked out since 2005 and there is a need to understand the gaps and check consistencies, etc. 

Best regards,

Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, June 29, 2010 10:37 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Proposed liaison to ITU-T on G.8110

Stewart,

Best regards

Alan

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 29 Jun 2010 12:22:56 +0200

Neil,
I think we discussed the need for TTL also in transport many times in the past. It is a another way to protect the network from errors such misconnectivity that create loops, etc. and to ensure that a packet does not "wander " in the network forever. This is also why we use an OAM CV function in the network.  CV can detect misconnectivity which results in a wrong endpoint receiving the traffic, but it cannot detect misconnectivity which results in loops. 
Do you think that TTL was modeled in G.8110 as part of the CI because of such a vision that the TTL function is not needed in transport networks? (still even if this is the case, it is not consistent with MPLS behavior). 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, June 29, 2010 1:03 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Proposed liaison to ITU-T on G.8110

regards, Neil

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Tue, 29 Jun 2010 12:34:24 +0200

Nurit,
 
I have already raised some specific questions for clarification about your last point.
 
What has been changed in MPLS TTL processing in the last 5 years? Why do you think TTL processing in MPLS-TP is different from TTL processing in MPLS? What are actually these differences?
 
I recall I raised a specific question during the last Q12/15 meeting to check whether the TTL processing in MPLS-TP is the same as in MPLS. All those present at that meeting (including ISOC representatives) agreed that the TTL processing is the same.
If this answer that I got at the meeting is incorrect, I would appreciate to understand why.
 
I do not buy the argument that G.8110 is five years old. RFC 3031 is nine years old but this is not precluding us to make normative reference to it.
 
During the development of G.8110.1 a lot of care has been taken by the editor and technical contributors to reuse the functional model of G.8110 when appropriate and to develop extensions to this model where needed.
 
I would appreciate if you can point to a specific technical item that has not been properly captured in this work.
 
Italo

________________________________

	From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
	Sent: martedì 29 giugno 2010 12.09
	To: [email-masked]; BUSI, ITALO (ITALO); [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Proposed liaison to ITU-T on G.8110

	Hi,

	Best regards,

	Nurit

	<<Snipped>>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 29 Jun 2010 12:51:13 +0200

Hi Italo,

Please see inline.

Best regards,

Nurit

-----Original Message-----
From: ext BUSI, ITALO (ITALO) [mailto:[email-masked]] 
Sent: Tuesday, June 29, 2010 1:34 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Proposed liaison to ITU-T on G.8110

Nurit,

What has been changed in MPLS TTL processing in the last 5 years? 

<Nurit> This was a general comment, not specific related to TTL. \<Nurit> 

Why do you think TTL processing in MPLS-TP is different from TTL processing in MPLS? What are actually these differences?

<Nurit> I do not think I have said it. \<Nurit>

<Nurit> Sure, but a lot of work has been done since then on MPLS architecture as documented in other documents. Is it the same in the ITU-T? do we have additional documents on MPLS architecture? \<Nurit> 

<Nurit> I am sure. Still we have the concern on the modeling of TTL as a CI. Please refer to my main points in the mail. AM I wrong? \<Nurit>

Italo

      Cc: [email-masked]

      

      Hi,

      Best regards,

      Nurit

      <<Snipped>>

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Tue, 29 Jun 2010 13:39:48 +0200

Nurit,

thanks for your reply. See in line marked with [ib]

Italo

________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]]
Sent: martedì 29 giugno 2010 12.51
To: BUSI, ITALO (ITALO); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Proposed liaison to ITU-T on G.8110

Hi Italo,

Please see inline.

Best regards,

Nurit

-----Original Message-----
From: ext BUSI, ITALO (ITALO) [mailto:[email-masked]]
Sent: Tuesday, June 29, 2010 1:34 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Proposed liaison to ITU-T on G.8110

Nurit,

[ib] The TTL processing in MPLS-TP is either identical to the TTL processing in MPLS or it is different.

If it is identical, G.8110.1 should model it exactly in the same way as G.8110.

A request to define a different model in G.8110.1 means to me that the TTL processing in MPLS-TP is different than in MPLS.

Am I missing something?

[ib] As said below, the ITU-T model for all the extensions to MPLS architecture defined by IETF after the approval G.8110 and relevent to MPLS-TP has been described in G.8110.1. G.8110.1 refers to G.8110 for the aspects that are were defined by MPLS at that time and still applicable to MPLS-TP (e.g., TTL processing).

[ib] G.8110.1 models the TTL processing in exactly the same way as G.8110. If the TTL processing in the same between MPLS-TP and MPLS, I think this is the right way to do. If this is not the case, I would like to understand what are the differences.

Italo

      Cc: [email-masked]

      Hi,

      Best regards,

      Nurit

      <<Snipped>>

---

From: <[email-masked]>
Date: Tue, 29 Jun 2010 12:48:25 +0100

Hi Nurit..... 

who wrote 29 June 2010 11:23

> Neil,
> I think we discussed the need for TTL also in transport many 
> times in the past.

NH=> I do not recall such a discussion in co-cs mode transport layer networks such as those in PDH, SDH or OTN.  I also do not recall it in any co-ps mode layer network technologies such as X.25, FR, ATM or PBB-TE.  Indeed there is no TTL function in any of these networks as they all only use proper single source connections, and so a TTL function is just a waste of processing/money.

> It is a another way to protect the network 
> from errors such misconnectivity that create loops, etc. and 
> to ensure that a packet does not "wander " in the network 
> forever.

NH=> Yes, in a cl-ps mode network using a routing function in an arbitrary topoplogy.  The other much more 'sledgehammer' way to handle this is to prune the topoology to a connectivity = 1 (so here we now don't need a routing function) which is what the cl-ps types of Ethernet do. 

We have TTL in MPLS-TP because it appears in MPLS....and of course the LDP form of MPLS demands it because we not 'set-up' proper single source parent connections.  So this is why we have TTL in MPLS-TP, it is not because it is a technical necessity...once we deprecate the LDP form of MPLS LSPs, as indeed we must in MPLS-TP, then we have removed the technical reason for wanting TTL in the first place in MPLS.

> This is also why we use an OAM CV function in the 
> network. 

NH=> I regard as quite misleading, and perhaps even rather disingenuous if one properly understands how each of the network modes work (see G.800), to compare a TTL function with a CV function.

> CV can detect misconnectivity which results in a 
> wrong endpoint receiving the traffic

NH=> This arises in the co-ps mode when we take short-cuts in the labelling of traffic units...an even better solution is not to take such labelling short-cuts at all and then the network is self-protecting against misconnectivity without any OAM at all.  

> but it cannot detect 
> misconnectivity which results in loops. 

NH=> This is actually not true...irrespective of the fact it is the wrong functional solution to the problem of *self-misconnectivity*, ie loops.  One can easily set an upper bound of say 4 CV packets in any 3 contiguous second periods, which means that any CV arrival rate above this threshold can be detected/clssified as a loop (I actually put this case into Y.1711 a long time ago just for completeness).  But we are really into corner cases here for total completeness of specification...if this has been such a problem then all prior types of co-ps mode network like X.25, FR and ATM would have been forced to incorprate a TTL function.  They did not do so, and this is not coincidence/luck.

> Do you think that TTL was modeled in G.8110 as part of the CI 
> because of such a vision that the TTL function is not needed 
> in transport networks? (still even if this is the case, it is 
> not consistent with MPLS behavior). 

NH=> We have TTL in here because MPLS has TTL.  A co-ps mode network does not require a TTL function...that statement is just obviously true...we have TTL in MPLS-TP because we have TTL in MPLS...and we have TTL in MPLS because of the LDP spin of MPLS.....it's a simple as that.  The fact it causes problems trying to model it in G.8110 is because it is not normal for a co-ps mode network to have a TTL function, ie there should not be a TTL function present at all because it is quite unnecessary.  I am sure the Q12 folks will spell-out the reasons for why the modelling looks like it does when a technically corrected liaison is sent to them.

regards, Neil 

> [mailto:[email-masked]] On Behalf Of ext 
> [email-masked]
> I agree with Alan that one should ask Q12 why they used a 
> specific approach for the modelling of TTL in MPLS.  However, 
> one has to observe that in a co-ps mode transport network 
> based on proper connections then a TTL function is 
> unnecessary....so asking whether we are accurately modelling 
> something that is just plain wrong is a rather strange thing 
> to focus on (and I'll wager this is why it has a strange 
> handling model in G.8110).
> 
> Perhaps Stewart's mail is the catalyst to ask the question 
> why we simply don't null the TLL function in MPLS-TP?
> 
> Aside=> We can't appeal to an argument that 'it's a profile 
> of MPLS' because MPLS-TP is creating a new layer co-ps mode 
> network technology since it adds new functional behaviours 
> not found in any existing spin of MPLS (eg logically OOB CP, 
> new addressing types, new OAM) in addition to reusing as much 
> of the existing MPLS specification as it can......even 
> inappropriate bits unfortunately....which is the case we have here.
> 
> regards, Neil
> 
> > Whilst I don't agree with your proposed liaison I'd like to make a 
> > suggestion. Your statement that " We note that according to 
> G.805, the 
> > CI is supposed to be delivered end-to-end between MPLS APs without 
> > modification or inspection" is incorrect by definition. CI 
> information 
> > is transferred between Termination Connection Points (TCPs) and not 
> > between AP's. Indeed the point of the source termination 
> function is 
> > to add information to adapted information which traverses 
> the AP and 
> > thus to generate CI and the corresponding sink processes 
> information.
> > 
> > This is quite clear from G.805 and is also well described in Sexton 
> > and Reid. I would therefore suggest you correct your liaison.
> > 
> > Regarding the model for TTL, I am sure that Q12 will be happy to 
> > explain the reasoning behind the way it was constructed and how the 
> > TTL value is decremented on a per hop basis. But perhaps it 
> might be 
> > more appropriate to ask for an explanation of how the model works 
> > before assuming that it is wrong.
> > 
> > Best regards
> > Alan
> >

---

From: Luca Martini <[email-masked]>
Date: Tue, 29 Jun 2010 03:05:40 -0600

Yes,
Thanks for catching the problem.
Luca