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

[<[e-mail]>]

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 

> Best regards,
> Nurit
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of ext 
> [e-mail]
> Sent: Tuesday, June 29, 2010 1:03 PM
> To: [e-mail]; [e-mail]; 
> [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls-tp] Proposed liaison to ITU-T on G.8110
> 
> 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
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of [e-mail]
> > Sent: 29 June 2010 08:37
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Stewart Bryant
> > > Sent: lunedì 28 giugno 2010 19.42
> > > To: [e-mail]
> > > Subject: [mpls-tp] Proposed liaison to ITU-T on G.8110
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > ==========
> > > _______________________________________________
> > > mpls-tp mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > 
> > _______________________________________________
> > mpls-tp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > _______________________________________________
> > mpls-tp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>