Subject: RE: on the mpls oam framework

From: "Punj, Arun" <[email-masked]>
Date: Tue, 11 Nov 2003 09:20:42 -0500

Loa/Allan/Folks,

I think it is important to accomodate people with opposing points of
view. But that, IMHO, does not require writing a new document. Specially 
when the opposing point of view has not articulated any point which would 
invalidate a substantial portion [or even a portion] of allan-mpls-oam 
draft. 

It would be a pity if a document which nicely captures all the issues
was relegated to backburner for reasons - which are not even remotely
technical. However, I am sure if you want Thomas Nadeau to work as 
a co-author to evolve this document further in the right direction it
would be welcome. Thomas is a highly respected engineer and we welcome
his feedbacks and guidance - and a chance to discuss his point of view.

Further comments inline.

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Monday, November 10, 2003 6:20 PM
> To: Shahram Davari
> Cc: MPLS wg; George Swallow; Alex Zinin
> Subject: Re: on the mpls oam framework
> 
> 
> Sharam,
> 
> note that Neil, Dave and I agree on that the disconnect is there,
> I'm not certain that they agree with how I described (but that
> is also part of the disconnect :) ).
> 
> Anyway - I guess that the core of the matter is that the architecture
> is written positioning mpls as a part of the ip protocol suite, while
> the oam framework rather position it as a "newer and better ATM" that
> necessarily needs to have all the features of ATM.
> 
> This shows up in a numbe of places, the concept of layers and levels
> is, not what I see as useful in the type of IP network I've been
> involved in.

Concept of layers and levels does show up in architecture document and
as the architecture document acknowledged MPLS is not IPLS. 

RFC 3031
   "label switched path       The path through one or more LSRs at one
                              level of the hierarchy followed by a
                              packets in a particular FEC."

   " MPLS stands for "Multiprotocol" Label Switching, multiprotocol
   because its techniques are applicable to ANY network layer protocol.
   In this document, however, we focus on the use of IP as the network
   layer protocol. "
> 
> The definition of "LSP" is not what is in the architecture document.
  
  Can you point out the difference ?

> 
> PHP is designed out by the oam framework, but an in by the mpls
> architecture.

  Thats incorrect. The allan-mpls-oam clearly identifies that pros
  and cons of PHP. And it identifes rightly, that PHP would 
  incur some implementation costs in so far as the OAM functionality
  is desired. And if you do not agree, look at the implementations
  for OAM out there.

  Further please look at following texts from RFC3031:
  
   "There is also a practical advantage to doing penultimate hop popping.
   If one does not do this, then when the LSP egress receives a packet,
   it first looks up the top label, and determines as a result of that
   lookup that it is indeed the LSP egress."
                    ^^^^^^^^^^^^^^^^^^^^^^^
   This "it is indeed the LSP egress" functionality loss with PHP is
   what causes many of the problems to appear, as identified clearly
   in allan-mpls-oam draft.

   Also from RFC 3031 [3.27.3. LSP Tunnels]:

   "If it is not necessary for the tunnel's receive endpoint to be able
   to determine which packets it receives through the tunnel, as
   discussed earlier, the label stack may be popped at the penultimate
   LSR in the tunnel."
  
   This section clearly identifies when PHP should and should not be
   used. Thus for desirable OAM features PHP should not be used. 
   Again, before any one starts distorting the words please refer 
   to allan-mpls-oam draft - it DOES include OAM for PHP implementations.

> 
> But you are misrepresenting me when you say that the differences is
> not resolvable. In fact the proposal to start on a fresh document
> is intended jsut to achieve that. I guess that if there are two people
> representing two different ideas on a subject, the 
> requirement that one
> of the has to accept the ideas of the other to be part work seems to
> be counter-productive.

Once we can clearly identify the differences - I am sure they can 
be resolved. Infact, mostly the differences seem to stem from the love
of what is out there - rather than what is correct. But even in that they
are unnecassary since allan-mpls-oam does not specifically rule out
any solution out there - regardless of its merits or rather lack of.

> 
> Further if we have a "default" document in this case it should be the
> architecture.

I think RFC3031 should be a guiding document and not starting point for
any new work done in MPLS.

Thanks
Arun

> 
> /Loa
> 
> Shahram Davari wrote:
> 
> >Loa,
> >
> >Could you please technically articulate were the disconnect is?
> >and why isn't it resolvable, so that it needs a new draft?
> >In other words please provide valid justification for your
> >request.
> >
> >Thanks,
> >-Shahram
> >
> >  
> >
> >>-----Original Message-----
> >>From: Loa Andersson [mailto:[email-masked]]
> >>Sent: Sunday, November 09, 2003 9:27 PM
> >>To: MPLS wg
> >>Cc: George Swallow; Alex Zinin
> >>Subject: on the mpls oam framework
> >>
> >>
> >>All,
> >>
> >>I read the mpls oam framework as it has been suggested in
> >>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
> >>re-read the the mpls architecture document. I've the architecture
> >>authors to review the oam framework and received some feedback
> >>    
> >>
> >>from them.
> >  
> >
> >>It is my understanding that there is a serious disconnect
> >>between the architecture and oam framework, and I therefore
> >>want to restart the oam framework in a fresh document,
> >>with the undertanding that this document shall be aligned
> >>with the architecture.
> >>
> >>I asked David Allan and Tom Nadeau to take on the editorship
> >>for this new document, and hope to have positive answers from
> >>both of them before the mpls wg meeting in Minneapolis.
> >>
> >>/Loa
> >>
> >>    
> >>
> >
> >
> >  
> >
>

---

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Tue, 11 Nov 2003 13:55:32 -0500

Hi,

Largely for the reasons already outlined by Loa, Curtis, Tom,
and George (apologies if I have misunderstood any of your
positions), I support re-starting the MPLS Management Framework
effort.  This framework should be as consonant as possible with
the existing MPLS Architectural Framework at this point in time.

As has also been pointed out, Dave, Neil, and others have made
some excellent observations that may need to be considered in
both future evolutions of the MPLS architecture documents and
ancillary/specific management-related documents.  But the baseline
MPLS Management Framework document needs to be as synergistic as
possible with standard MPLS architecture and with the most common
current and near-term deployment scenarios.

Cheers,

BobN

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Tuesday, November 11, 2003 1:07 PM
> To: Shahram Davari
> Cc: [email-masked]'; David Allan; [email-masked]'; MPLS wg; George
> Swallow; Alex Zinin
> In message 
> <[email-masked]
> sierra.bc.ca>, Shahram Davari writes:
> >  
> > Curtis,
> >  
> > I think you are misreading the draft. It doesn't say that there
> > shouldn't be any OAM tools for ECMP, PHP, Mp2p. All it says is that
> > special considerations and complexities are involved in those cases,
> > and it outlines the issues that needs to be considered 
> while designing
> > an OAM tool.
> >  
> > So I don't see your point as a valid point to discard this 
> draft, and
> > I am sure many other WG members agree with me.
> >  
> > Yours,
> > -Shahram
> 
> 
> I think the draft as is could be submitted as an informational draft
> submitted by Dave outside the work group.
> 
> As a framework for OAM it is a diversion from progress rather than a
> step toward progress.  It would be enough to give a simple statement
> that any form of OAM which simply injects traffic at ingress and
> counts traffic at egress is insufficient in many circumstances and
> perhaps briefly enumerate the circumstances rather than describe them
> in detail.  The framework can then outline requirements agreed to in
> the WG and if it follows other framework documents it may touch on
> solution approaches concentrating on those that work within the entire
> framework (work in all cases, meet the largest set of requirements).
> Mention can be made of those approaches that work in a limited context
> but the overall emphasis should not be on evaluation of the
> implications of network topology on a specific solution that has been
> rejected by the WG.
> 
> Curtis
>

---

From: "David Allan" <[email-masked]>
Date: Sat, 15 Nov 2003 05:15:55 -0500

Hi Kireeti:

> > IMHO You are persisting in ignoring what you don't want to see.
> 

I understand what you're seeing in the marketplace. 

My point was that the ITU work has progressed beyond the low hanging fruit
of p2p, and (for example) Y.17fec-cv is directed at LDP/ECMP etc. and for at
least PW and VPN applications, could also work with PHP. It is when an LSR
offers a lot of FEC/label bindings at the LDP/IP layer that fec-cv would
lose precision in the PHP scenario. 

I've discussed this at conferences we've all been at, posted drafts,
presented this stuff (in SF) yet folks persist in characterizing the ITU
work as focused on an insignificant corner case. I don't think it is that
insignificant, but it is not the only thing going on....

later
Dave

---

From: [email-masked]
Date: Sat, 15 Nov 2003 17:48:27 -0000

Kireeti wrote 15 November 2003 06:15

> On Mon, 10 Nov 2003 [email-masked] wrote:
> 
> > ie one can't fix what is wrong/missing in MPLS by
> > asking Dave to redo his paper...as its simply a statement of fact
> > and is therefore 'right'.
> 
> As co-author of the wrong approach, I will be happy to help Tom with
> his wrong OAM framework for the wrong MPLS architecture we so wrongly
> have.  We would be wrong to make Dave wrong when he is so right.
> 
> Kireeti.
> -------
Kireeti.....if you were serious about this I, and many folks here, would be grateful.  The simple fact of the matter is this:

-	a cnls mode *must* have a network-unique SA/DA pair in each traffic unit.  Most fundamemtal of all, this means the cnls mode always *multiplexes and never merges* traffic units.  This observation is significant, and determines how this mode is specified and how it is managed, eg OAM is one such facet.

-	a co-ps mode does not have a network-unique SA/DA pair in each traffic unit...it usually only has a link-unique 'DA' (link-connection ID) per hop.  These need stitching together and have to belong to some parent trail connection entity.....and further, until they are, the link-connection IDs have no network currency.  This means that only p2p and p2mp topologies are allowed in this mode, ie to ensure source uniqueness.  Sure you can do mp2p but this results in merging and means we lose sight of the source.  The only way to recover from the effects of merging is either:
	* by running a further p2p client connection entity above the mp2p server connection entity, or
	* by a priori knowledge that the direct client is cnls and posseses a network-unique DA/DA pair per traffic unit.
Again, the nature of the co-ps traffic unit has a fundamantal bearing on how this mode must be specified and how it requires to be managed, eg OAM is one such facet, and it is every different to the cnls mode.  So when one constructs a mp2p connection entity in the co-ps mode then one creates some significant traffic and fault-management problems that do not occur in either (i)  co-ps p2p and p2mp topologies or (ii) the cnls mode.

Now the above are simply facts of the 2 modes that neither I, nor you, can change.  To ignore them however and somehow pretend its not true or not significant is not very sensible IMO.

PHP is something else entirely, ie stop the trail 1-hop short of its true end-point.  However, moving the trail termination function like this does create problems as I am sure you well know.

Dave's document is merely stating the factual consequence of things like mp2p merging and PHP on the OAM behaviour.  

regards, Neil

---

From: [email-masked] (Scott Bradner)
Date: Sat, 15 Nov 2003 19:22:58 -0500 (EST)

> I have an idea of what consitutes data plane OAM, and thought that had been
> delegated to the ITU with RFC 3429. I also thought Scott had a pretty clear
> demarcation in viewing ping and traceroute as IETF balliwack but the other
> "telco" stuff out of scope.

out of scope mostly because it was out of interest for many in the IETF
(we had such fun discussions on the topic :-) )

Scott

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Sun, 16 Nov 2003 17:01:40 +0100

"Whoa, meme merde, autre jour ;-)"

C'est quoi comme langage cher David??

"We already have LSP-PING, LSR-SELF-TEST (a ping derivative), VCCV (a ping++
derivative) none of which so far would appear to have required charter
changes by the previous operating definition. We also now have BFD which is
more in the 1711 class of tools. On the other side of the house we have
Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping this stuff in
a bit of context, what extra needs doing?"

One minor nit:  y.1712, fec-cv are currently draft ITU-T recommendations and have not yet attained approved recommendation status yet as these are still being discussed -- certainly shall be this week at the interim ITU-T meeting in Geneva - should also add same for y.1711 revised btw.

Amicalement,

/monique

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan
Sent: 15 November 2003 23:03
To: [email-masked]'; [email-masked]; [email-masked]
Cc: [email-masked]; George Swallow (swallow); [email-masked]
Subject: RE: on the mpls oam framework

Whoa, meme merde, autre jour ;-)

One of the goals of the framework draft we brought forward was to facilitate
understanding of the implications of particular aspects of the architecture
when it came to measurement and fault detection. Some things were
impossible...end of story. We can enumerate this individually by solution if
we want to go down that route, but ultimately that analysis in some form is
required if the document is to have any semblance of intellectual and
practical honesty and be useful to the industry. Those particular aspects in
whatever form they take are important to bring forward, as simply
enumerating the solution space without "criticism" is useless. To also
pretend these things do not have impact because an extra million lines of
code, a few generations of Moores law and protocol design can sort it out is
also IMO not useful.

I have an idea of what consitutes data plane OAM, and thought that had been
delegated to the ITU with RFC 3429. I also thought Scott had a pretty clear
demarcation in viewing ping and traceroute as IETF balliwack but the other
"telco" stuff out of scope. Clearly that has changed and what that means
needs some elucidation. That the can of worms has been reopened at the IETF
is clear, and it behooves me to chime in, but I'm not clear on precisely why
it has been reopened.

We already have LSP-PING, LSR-SELF-TEST (a ping derivative), VCCV (a ping++
derivative) none of which so far would appear to have required charter
changes by the previous operating definition. We also now have BFD which is
more in the 1711 class of tools. On the other side of the house we have
Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping this stuff in
a bit of context, what extra needs doing?

cheers
Dave

---

From: "David Allan" <[email-masked]>
Date: Sun, 16 Nov 2003 12:49:49 -0500

> C'est quoi comme langage cher David??

Comes from a long Euro-travel cycle ;-)

> One minor nit:  y.1712, fec-cv are currently draft ITU-T 
> recommendations and have not yet attained approved 
> recommendation status yet as these are still being discussed 

Still up in the air like everything else on the list ;-)

> certainly shall be this week at the interim ITU-T meeting in Geneva

I'm already there....

rgds
Dave

> One of the goals of the framework draft we brought forward 
> was to facilitate understanding of the implications of 
> particular aspects of the architecture when it came to 
> measurement and fault detection. Some things were 
> impossible...end of story. We can enumerate this individually 
> by solution if we want to go down that route, but ultimately 
> that analysis in some form is required if the document is to 
> have any semblance of intellectual and practical honesty and 
> be useful to the industry. Those particular aspects in 
> whatever form they take are important to bring forward, as 
> simply enumerating the solution space without "criticism" is 
> useless. To also pretend these things do not have impact 
> because an extra million lines of code, a few generations of 
> Moores law and protocol design can sort it out is also IMO not useful.
> 
> I have an idea of what consitutes data plane OAM, and thought 
> that had been delegated to the ITU with RFC 3429. I also 
> thought Scott had a pretty clear demarcation in viewing ping 
> and traceroute as IETF balliwack but the other "telco" stuff 
> out of scope. Clearly that has changed and what that means 
> needs some elucidation. That the can of worms has been 
> reopened at the IETF is clear, and it behooves me to chime 
> in, but I'm not clear on precisely why it has been reopened.
> 
> derivative) none of which so far would appear to have 
> required charter changes by the previous operating 
> definition. We also now have BFD which is more in the 1711 
> class of tools. On the other side of the house we have 
> Y.1710/11/12/20/fec-cv. With the exception of perhaps 
> wrapping this stuff in a bit of context, what extra needs doing?
> 
> cheers
> Dave
> 
> 
>

---

From: [email-masked]
Date: Mon, 17 Nov 2003 10:17:13 -0000

Curtis,
Curtis Villamizar wrote 16 November 2003 22:24
> In message 
> <[email-masked]
> host.net>, [email-masked] writes:
> > Kireeti Kompella wrote 15 November 2003 06:47
> > > Hi Dave,
> > > 
> > > On Tue, 11 Nov 2003, David Allan wrote:
> > > 
> > > Speaking as a vendor:
> > > On mp2p: at least 90% of the MPLS deployments I've seen use LDP.
> > NH=> Does this make it 'right' then?  If the dominant 
> vendor 'does this' then
> >  your conclusions are hardly surprising.  Most of the world 
> also uses MS Wind
> > ows/applications too.....my PC crashes nearly every 
> day....I wish I could sor
> > t/change it but I can't.  Market dominance is a very 
> powerful vehicle IMO ;-)
> > > 
> > > On ECMP: many providers ask us explicitly for ECMP.  On the other
> > > hand, no provider that I know (other than BT) of has complained
> > > about ECMP and asked us to turn it off.
> > NH=> ECMP is a *consequence* of LDP because one cannot 
> control the routing.
> > > 
> > > On PHP: two providers (one being BT) have complained 
> about PHP, out
> > > of all the providers I've talked to about MPLS (about 3%).
> > NH=> You live with what you have been given by the dominant 
> vendors....again 
> > this does not make it right.  Can you tell me how many 
> operators actually ask
> > ed for PHP (or even LDP) as a requirement in the 1st place, 
> as I don't know o
> > f any network/service problem it solves?
> > 
> > regards, Neil
> 
> 
> They are needed for other technical reasons that are out of scope for
> the OAM framework.
NH=> I'd like to hear of the operational/service reasons as to how this benefits operators.

>  As far as the OAM framework is concerned, they are
> part of the architecture
NH=> With all due respect, I don't really see any 'architecture'.  I see a technology that worries about its implications later, eg the recent ECMP-hack/PWE3 aliasing problem.  G.805 and G.809 define formal functional architectures for the co-cs, co-ps and cnls modes.  And they have been proved very useful for >10 years now.

> and widely deployed so they must be supported
> by OAM tools.
NH=> This is true ....and yes I fully accept we have to live with this stuff whilst it is still in-service.

> It simply means that working with PHP and ECMP are
> requirements for OAM.
> You seem to have things backwards.  You have an OAM solution in mind
> that doesn't work well with ECMP and PHP and want a OAM framework that
> claims these are bad features.
NH=> Well that's an interesting view.  I could easily re-spin this remark and say you have a technology in-mind and will worry about its implications later.  If you cast your mind back a year or so, we were told (paraphrased) 'if you are having problems then buy kit from a decent supplier, don't fix it with adding OAM'.  Things seems to have a changed a bit since then ;-)

I have an OAM solution in mind that is designed to work with topological constructs that are valid for a co-ps (ie label swapping) forwarding mode.....to be perfectly honest with you Y.1710 (requirements) and Y.1711 (mechanisms) were written to apply to *any* co-ps technology, they were not specifically penned for MPLS.  I see nothing wrong with that....in fact if it did not meet this then it would be wrong.  In any case, the OAM solution is only one consequential facet of this observation....traffic and performance considerations are also impacted.

Architecturally it is simply a fact that merging loses resolution of the source, and this has nothing to do with OAM per se but it sure impacts it.....if you want any-any behaviour the right modal choice is cnls as that never merges only muxes.  How on earth you can tell me straight-faced this is not true beats me.

One of my colleagues is about to formally model MPLS as-is using the functional architecture language of G.805 (yes I know you probably think this is all wrong too, but we need it to develop management information models), and this will clearly show that mp2p and PHP are violations of the co-ps mode.  I cannot do anything about this, and this has nothing to do with my OAM solution for valid co-ps constructs....it is simply a fact.
> 
> This exercise includes stating requirements - and like it or not ECMP
> and PHP are requirements for OAM and so is not requiring changes to
> the forwarding plane.
NH=> Its nothing to do with whether I 'like it or not'.  There are certain network architectural truths and there are violations of these.  Pointing out the consequences of these (as per Dave's paper) should not be scolded as heresy....I'd say it should be welcomed by open-minded people.  But as noted earlier, please note I am also *not* saying we can ignore what has been done simply because we have recognised in hindsight doing certain things were not very good ideas.  We have to find ways of coping with these things (as they are now done and we cannot undo them).....but that is not the same as saying they are right from here on in.

> The framework can then discuss a set of
> solutions and their tradeoffs.  If a single solution (or set of
> solutions) covers all requirements well, then any additional partial
> solutions will be redundant.
NH=> Not if the super-set that encompasses arch violations still does not meet our service and operational requirements at the right complexity/cost it doesn't.  After what 2-3 years?, I still don't see any formal definitions of MPLS defects and their automatic detection and handling (in terms of consistent entry/exit criteria and consequent actions) in any IDs yet.  However, simple and complete solutions are given in Y.1711.  Given MPLS figures on most vendors and operators road-maps, and that opex reduction is a primary consideration for all operators these days, if we do not provide simple automatic defect detection/handling this will not be not acceptable to us going forward.  However, this is not in the least surprising since I have no idea how to do this directly for a mp2p entity.....except by using indirect techniques like Dave has suggested in the current framework paper, eg run p2p LSPs using Y.1711 above the mp2p entities....which you need to anyway for non-cnls clients as its the only way to demerge.  I don't see what is wrong with suggestions like this, and if you want to re-spin Dave's paper to remove this type of observation then I think you are doing the larger community a dis-service.

Note - I intend to make this my last posting on this topic as I simply cannot see any point in continuing to try and argue the case here, the logic of what I have stated above is self-evident IMO and I cannot think what more can be said.

regards, Neil

---

From: John Drake <[email-masked]>
Date: Mon, 17 Nov 2003 12:10:23 -0800

Very well put

> From: Rahul Aggarwal [mailto:[email-masked]]
> Sent: Monday, November 17, 2003 11:51 AM
> To: David Allan
> Cc: [email-masked]'; [email-masked]
> > BTW, would be nice to get some other opinions, IMHO this is rather
> > fundamental....
> >
> 
> To reiterate what has already been said on this thread. A MPLS OAM
> framework document must a) Follow the MPLS architecture and b) Discuss
> an OAM framework that concerns *practical* problems seen in 
> MPLS deployments.
> 
> If folks have issues with MPLS architecture/usage, it should 
> be documented
> elsewhere, not in the OAM framework document.
> 
> Regards,
> rahul
> 
> 
> > cheers
> > Dave
> >
> >
>