Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

[<[e-mail]>]

Hi Dave....some general observations in-line: 

David Allan wrote 18 February 2009 21:58

> HI Italo:
> 
> Misbranching detection assumed the packet was received by a node that
> implemented the standard and could determine on the basis of packet
> contents that there was a problem.
NH=> The key point here is that the CI of a layer network needs to be
consistent so that when traffic units end up in the wrong place their
functional fields can be parsed/interpreted in a consistent manner...and
this crucially includes the OAM as this should be generated/removed at
trail termination points (ie below the C/S adaptation function and
consistent for all clients).  In MPLS we don't even have consistent
label semantics.  Further, if one has a 'tool kit' of different OAM
solutions then this is even worse since we can't even assume the
consistent interpretation of this either when it is misdirected and
arrives at some arbitrary LSP trail termination point.....which is why I
favour consistent simple/sparse OAM for the always-on defect
detection/handling OAM.

> An OAM packet turning up somewhere
> that does not understand would likely just be silently 
> discarded...which
> I believe is the scenario being discussed...
 NH=> The probability of (i) misforwarding vs (ii) black-holing in a
label-swapping co-ps network is a function of:
-	how many labels from the total label space are in use on each
link connection;
-	what the allocation policy is for labels.....if not 'random' in
some way but always allocated in a systematic/same way on each link
connection, then one could find a high probability of misforwarding even
when only a few labels are actually in use.
 
> 
> At a minimum, ability to detect inappropriate connection of T-MPLS and
> MPLS together would require MPLS implementations be modified 
> to alarm on
> terminating a packet with an RFC 3429 label.
NH=> True.  But a plea from history here.  This solution of using a
further header (with a special OAM alert label) over normal traffic is a
dreadful idea, since this means that OAM looks different to normal
traffic.  The OAM indicate flag should be an intrinsic part of the
normal traffic unit header because we need OAM and traffic units to look
as identical as possibble in the DP.  When I was drafting Y.1711 I could
not get this....the MPLS header is not functionally rich, and there was
no way to get access to the EXP and TTL fields.  There is actually no
excuse for this in MPLS-TP.  For one thing the TTL field should be
redundant is an properly designed co-ps mode transport network.  But if
this cannot be used then some other way must be found where both traffic
and OAM look the same.  And if you look at the proposal from John Drake
and myself this would work like this....as the OAM indicate flag would
use a different PID value than normal (client) traffic......though I
should also point out that the TTL and EXP bits are also largely
redundant (and quite rightly so) in this proposal (indicated by S=1 =>
ie BOS header always contains a PID function (in place of the normal
forwarding label for case S=0)).

> Similarly T-MPLS would be
> obliged to alarm on receipt of any IP packet with a 127/ 
> address or some
> similar heuristic. Unfortunately in both cases the point where
> inappropriate interconnection was actually detected could be many hops
> removed from the actual problem...
NH=> If we have X different types of OAM to detect/handle defects then
each LSP trail termination point should also be ready and able to handle
X different OAM types arriving...as who knows what kind of traffic might
get misdirected to it.  But what a silly situation this would be!  This
is why I stated above that even if we have screwed-up on having
consistent CI wrt to what labels mean in MPLS, the OAM really needs to
be *identical* for all LSP cases...else you get into this combination
issue with the OAM.  This is why I don't like these references to 'OAM
tool kits' and lots of options for the always-on defect
detection/handling OAM....this needs to be simple/sparse and consistent
across all LSPs.

> 
> Not sure anyone is going to rush out to implement those
> safeguards...what is more likely is that the T-MPLS trail 
> simply appears
> broken and is traced until the interconnect point is found (however I
> believe that is going to be via MIB dumps given the state of 
> G.8112)...
> I'm not sure that qualifies as detection
NH=> Quite Dave.  It has no need to be like this of course....but it
requires sticking rigidly to a few key arch principles from the outset
and not violating them.  I'll spare folks a list of what was done poorly
in MPLS....but it will be unforgivable if these same mistakes now also
appear in MPLS-TP.

regards, neil
> 
> D
> 
>  
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of BUSI ITALO
> Sent: Wednesday, February 18, 2009 7:06 AM
> To: Loa Andersson
> Cc: [e-mail]
> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
> MPLS-TP
> 
> The first version of T-MPLS OAM tools are defined in ITU-T 
> (approved and
> in-force) Recommendation G.8112
> 
> G.8112 CV is powerful enogh to detect misconnections
> 
> Italo
> 
> > -----Original Message-----
> > From: Loa Andersson [mailto:[e-mail]]
> > Sent: Wednesday, February 18, 2009 11:45 AM
> > To: BUSI ITALO
> > Cc: Andrew G. Malis; [e-mail]
> > Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on 
> > MPLS-TP
> > 
> > Italo,
> > 
> > exactly what are you referring to here? Where are "the 
> powerful T-MPLS
> 
> > OAM tools" documented?
> > 
> > /Loa
> > 
> > BUSI ITALO wrote:
> > > Andy,
> > > 
> > > T-MPLS provides powerful OAM tools to detect any
> > misconfiguration errors
> > > and prevent "accidental interconnection of IP/MPLS and
> > transport layer
> > > MPLS"
> > > 
> > > Italo
> > > 
> > >> -----Original Message-----
> > >> From: Andrew G. Malis [mailto:[e-mail]]
> > >> Sent: Saturday, February 07, 2009 11:10 PM
> > >> To: [e-mail]
> > >> Cc: Thomas Nadeau; BUSI ITALO; [e-mail]
> > >> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the 
> cooperation on
> 
> > >> MPLS-TP
> > >>
> > >> Sharam,
> > >>
> > >> The IP/MPLS Forum has defined the MPLS Inter-Carrier 
> Interconnect 
> > >> Specification (
> > http://www.ipmplsforum.org/tech/IPMPLSForum19.0.0.pdf
> > >> ). Just this past week I was in discussion with a large
> > European-based
> > >> interconnect provider (they interconnect several hundred service 
> > >> provider networks) that has customers interested in 
> interconnecting
> 
> > >> using this specification. I know of several other
> > providers that have
> > >> also expressed interest.
> > >>
> > >> In addition, Verizon (for one) has widely deployed MPLS in
> > its public
> > >> and private IP backbone networks and intends to deploy
> > MPLS-TP in its
> > >> transport network. We are extremely concerned with 
> precluding any 
> > >> potential harm through the accidental interconnection of
> > IP/MPLS and
> > >> transport layer MPLS, either through operational or provisioning 
> > >> error, or though physical misconnections in a CO. With 
> MPLS-TP, we 
> > >> know that potential harm can be precluded. We cannot be so
> > sure with
> > >> T-MPLS as defined in the current recommendations.
> > >>
> > >> Cheers,
> > >> Andy
> > >>
> > >> On Sat, Feb 7, 2009 at 10:10 AM, Shahram Davari 
> <[e-mail]>
> 
> > >> wrote:
> > >>> Tom,
> > >>>
> > >>> What I meant was that MPLS/T-MPLS are not used at Internet
> > >> peering points
> > >>> (E-NNI). Off course a single ISP can use MPLS or T-MPLS
> > in their own
> > >>> network, but they are in full control of their own network
> > >> and could make
> > >>> sure incompatible protocols are not used or are used in a
> > >> controlled manner.
> > >>> -Shahram
> > >>>
> > >>> -----Original Message-----
> > >>> From: Thomas Nadeau [mailto:[e-mail]]
> > >>> Sent: February-07-09 9:58 AM
> > >>> To: [e-mail]
> > >>> Cc: 'Adrian Farrel'; 'Thomas Walsh'; [e-mail]; 
> > >>> [e-mail]; 'BUSI ITALO'; [e-mail]
> > >>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the
> > >> cooperation on MPLS-TP
> > >>>
> > >>>
> > >>>> Hi Adrian and Tom,
> > >>>>
> > >>>> I am personally in favour of deprecating T-MPLS, because I
> > >> think the
> > >>>> industry needs one set of standard and having two will lead to 
> > >>>> confusion.
> > >>>> But  I don't think T-MPLS is dangerous for the public 
> "Internet" 
> > >>>> (sine MPLS or T-MPLS are not used in the public Internet) ,
> > >>>        Sharam,
> > >>>
> > >>>        I am a little surprised by your assertion above that
> > >> MPLS is not
> > >>> used
> > >>> in
> > >>> the public Internet.  The reality is quite the contrary.  
> > >> Perhaps you
> > >>> meant something
> > >>> else or this is a typo?
> > >>>
> > >>>        --Tom
> > >>>
> > >>>
> > >>>
> > >>>> and I also don't think not
> > >>>> following IETF change procedures is a convincing
> > argument (because
> > >>>> one might
> > >>>> come up with a valid protocol without following the 
> IETF change 
> > >>>> process).
> > >>>>
> > >>>> Best regards,
> > >>>> Shahram
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: [e-mail]
> > [mailto:[e-mail]] On
> > >>>> Behalf
> > >>>> Of Adrian Farrel
> > >>>> Sent: February-06-09 3:59 PM
> > >>>> To: [e-mail]; 'Thomas Walsh'; [e-mail]; 
> > >>>> [e-mail]
> > >>>> Cc: 'BUSI ITALO'; [e-mail]
> > >>>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the
> > cooperation on
> > >>>> MPLS-TP
> > >>>>
> > >>>> Shahram,
> > >>>>
> > >>>> Trying to defuse a little...
> > >>>> I'm not sure that discussing the IETF behavior is
> > entirely helpful,
> > >>>> but for
> > >>>> reference, RFCs that are "replaced" are marked in the 
> RFC list as
> 
> > >>>> 'obsolete.' RFCs that are no longer relevant are marked as 
> > >>>> 'historic' and RFCs that are considered harmful are 
> obsoleted by 
> > >>>> a new RFC that describes how they are harmful.
> > >>>>
> > >>>> What is at stake here is what is most helpful to the 
> community at
> 
> > >>>> large. If a technology (e.g. T-MPLS) is being replaced 
> by another
> > technology
> > >>>> (MPLS-TP)
> > >>>>
> > >>>> by wide consensus of the community (ITU-T and IETF) it is not 
> > >>>> helpful to allow people to think that the old 
> technology is still
> > >> valid and worth
> > >>>> implementing. Doing so would mislead people into
> > thinking that they
> > >>>> there is
> > >>>>
> > >>>> community support for the technology. A new hardware
> > company coming
> > >>>> to the
> > >>>> list of Recommendations might conclude that the industry
> > >> supports the
> > >>>> technology and might waste valuable development time 
> pursuing the
> 
> > >>>> technology.
> > >>>>
> > >>>> Given that the IETF has persuaded the ITU-T that T-MPLS
> > should not
> > >>>> be worked
> > >>>>
> > >>>> on further and should be replaced by MPLS-TP, it is 
> dangerously 
> > >>>> misleading to leave the T-MPLS Recommendations "lying around".
> > >>>>
> > >>>> The agreement in Geneva seems to have been a 
> compromise. The IETF
> 
> > >>>> requested that the ITU-T should delete the existing T-MPLS 
> > >>>> Recommendations.
> > >>>> The ITU-T
> > >>>> has decided to leave the Recommendations in place 
> until they are 
> > >>>> "replaced"
> > >>>> by the v2 Recommendations that will move to MPLS-TP. It is
> > >> debateable
> > >>>> whether this replacement will mean that the v1
> > Recommendations are
> > >>>> 'deprecated', 'obsoleted', or merely 'replaced'. It would seem 
> > >>>> sensible, however, to note that G.xxxx v2 completely replaces
> > G.xxxx v1 even
> > >>>> if the
> > >>>> latter remains available in the repository. Someone
> > implementing or
> > >>>> deploying G.xxxx would take the most recent version.
> > >>>>
> > >>>> Actually, I had some reservations about the agreement in
> > Geneva. It
> > >>>> seems to
> > >>>>
> > >>>> me to be predicated on the ITU-T pulling its finger out and 
> > >>>> producing the v2
> > >>>>
> > >>>> Recommendations. As yet I have not seen even an editor's
> > revisions
> > >>>> of any
> > >>>> one Recommendation (perhaps I have not looked in the
> > right place?).
> > >>>> If the
> > >>>> ITU-T is not willing to produce this work I must assume
> > >> that the JWT
> > >>>> agreement is not backed by meaningful intent.
> > >>>>
> > >>>> Cheers,
> > >>>> Adrian
> > >>>> ----- Original Message -----
> > >>>> From: "Shahram Davari" <[e-mail]>
> > >>>> To: "'Thomas Walsh'" <[e-mail]>; 
> <[e-mail]>; 
> > >>>> <[e-mail]>; <[e-mail]>
> > >>>> Cc: "'BUSI ITALO'" <[e-mail]>;
> > >> <[e-mail]>
> > >>>> Sent: Friday, February 06, 2009 7:50 PM
> > >>>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the
> > cooperation on
> > >>>> MPLS-TP
> > >>>>
> > >>>>
> > >>>>> Hi Tom,
> > >>>>>
> > >>>>> AFAIK IETF doesn't remove an obsolete RFC from its 
> server (e.g.
> > >>>>> RFC2598).
> > >>>>> Are you then asking that ITU should remove obsolete
> > >> recommendations
> > >>>>> from
> > >>>>> its
> > >>>>> server.
> > >>>>>
> > >>>>> Regards,
> > >>>>> Shahram
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: [e-mail]
> > >> [mailto:[e-mail]] On
> > >>>>> Behalf
> > >>>>> Of Thomas Walsh
> > >>>>> Sent: February-06-09 2:16 PM
> > >>>>> To: [e-mail]; [e-mail]; 
> [e-mail]
> > >>>>> Cc: BUSI ITALO; [e-mail]
> > >>>>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the
> > >> cooperation on
> > >>>>> MPLS-TP
> > >>>>>
> > >>>>> Sharam,
> > >>>>>
> > >>>>> Please note I am not speaking for Stewart here, but
> > this is my own
> > >>>>> reaction to what you just said.
> > >>>>>
> > >>>>> These are two necessary steps for sure and as far as I
> > >> know are being
> > >>>>> followed.  I see nothing inconsistent in what Stuart said.
> > >>>>>
> > >>>>> Bottom line:
> > >>>>> The T-MPLS Recommendations were never submitted according
> > >> to the IETF
> > >>>>> change process and hence must be removed.
> > >>>>>
> > >>>>> Monique and I just spent two weeks in January at ITU-T SG
> > >> 13 and SG
> > >>>>> 11.
> > >>>>> We generally found very good cooperation in their
> > >> understanding that
> > >>>>> they can not publish any change to IP or an MPLS 
> protocol in a 
> > >>>>> Recommendation without following the IETF change process.
> > >>>>>
> > >>>>> The JWT agreement had two options (1) and (2).
> > >>>>>
> > >>>>> Option 2 would allow publication of T-MPLS
> > >> Recommendations by ITU-T
> > >>>>> as
> > >>>>> they currently exist as long as they remove the MPLS 
> Ethertype.
> > >>>>>
> > >>>>> Option (1) does not allow use of the MPLS Ethertype 
> in an ITU-T 
> > >>>>> Recommendation unless it's a protocol approved by IETF
> > >> according to
> > >>>>> its
> > >>>>> change process.  And this option conforms to the IETF
> > >> Change process.
> > >>>>> Please do not quote JWT agreements out of context. The
> > >> JWT agreement
> > >>>>> does not give ITU-T the right to ignore the IETF 
> change process.
> > >>>>>
> > >>>>> ITU-T may freely use IETF approved protocols.  T-MPLS
> > is not IETF
> > >>>>> approved according to the change process. IETF has a
> > >> right to ask for
> > >>>>> these offending documents to be withdrawn.
> > >>>>>
> > >>>>> Just my view,
> > >>>>>
> > >>>>> Tom
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: [e-mail]
> > >> [mailto:[e-mail]] On
> > >>>>> Behalf
> > >>>>>> Of Shahram Davari
> > >>>>>> Sent: Friday, February 06, 2009 10:08 AM
> > >>>>>> To: [e-mail]; [e-mail]
> > >>>>>> Cc: 'BUSI ITALO'; [e-mail]
> > >>>>>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the
> > >> cooperation on
> > >>>>> MPLS-
> > >>>>>> TP
> > >>>>>>
> > >>>>>> Hi Stewart,
> > >>>>>>
> > >>>>>> Here is your own report:
> > >>>>>>
> > >>>>>>
> > >> 
> > http://www.ietf.org/internet-drafts/draft-bryant-mpls-tp-jwt-report-
> > >>>>>> 00.txt
> > >>>>>>
> > >>>>>> and here is what it says in your report that ITU-T
> > agreed to do:
> > >>>>>>
> > >>>>>> - Alignment of the current T-MPLS ITU-T Recommendations
> > >> with MPLS-TP
> > >>>>>>      and,
> > >>>>>> - Termination of the work on current T-MPLS.
> > >>>>>>
> > >>>>>> I can't see anywhere in the report the term or intention of
> > >>>>> deprecating.
> > >>>>>> Could you please clarify which part of this report indicates
> > >>>>> deprecating?
> > >>>>>> Thanks,
> > >>>>>> Shahram
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: [e-mail]
> > >> [mailto:[e-mail]] On
> > >>>>> Behalf
> > >>>>>> Of Stewart Bryant
> > >>>>>> Sent: February-06-09 12:35 PM
> > >>>>>> To: [e-mail]
> > >>>>>> Cc: BUSI ITALO; [e-mail]
> > >>>>>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the
> > >> cooperation on
> > >>>>> MPLS-
> > >>>>>> TP
> > >>>>>>
> > >>>>>> Huub van Helvoort wrote:
> > >>>>>>> Stewart,
> > >>>>>>>
> > >>>>>>> You replied:
> > >>>>>>>
> > >>>>>>>>> So by keeping the word "depreciation" in the
> > liaison response
> > >>>>>>>>> the whole discussion will start again and as 
> Stuart already 
> > >>>>>>>>> mentioned a few times, this is a waste of time and
> > resources.
> > >>>>>>>>> And also it confuses the industry about the position
> > >> of the IETF.
> > >>>>>>>> There is no confusion about the position of the 
> IETF. It has 
> > >>>>>>>> quite clearly stated that T-MPLS is a potential 
> danger to the
> 
> > >>>>>>>> Internet and should not be deployed.
> > >>>>>>>>
> > >>>>>>>> The most appropriate action under such circumstances is 
> > >>>>>>>> deprecation of the protocol.
> > >>>>>>> Does this mean that you do not accept the agreement 
> documented
> 
> > >>>>>>> in the JWT report and WP3 report and that all the
> > time spent to
> > >>>>>>> discuss these agreements is wasted and that you 
> want to start 
> > >>>>>>> this discussion again.
> > >>>>>>>
> > >>>>>> Huub
> > >>>>>>
> > >>>>>> I can see no logical linkage between my statement and your 
> > >>>>>> deduction. Please will you explain it to me.
> > >>>>>>
> > >>>>>> Stewart
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> 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
> > >>>>>
> > >>>> _______________________________________________
> > >>>> 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
> > 
> > --
> > 
> > 
> > Loa Andersson
> > 
> > Sr Strategy and Standards Manager
> > Ericsson ///                          phone:  [phone]
> > 
> >                                        email:  
> > [e-mail]
> >                                                
> > [e-mail]
> >                                                [e-mail]
> > 
> > 
> > 
> _______________________________________________
> 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
>