Subject: RE: on the mpls oam framework

From: "David Allan" <[email-masked]>
Date: Mon, 17 Nov 2003 09:16:47 -0500

Tom:

I have to admit, the whole ECMP thing provides me with endless amusement.
Pull a proprietary rabbit out of your hat and then paint those previously
ignorant of your "feature" as clueless. If you'd been upfront with the fact
that there was a problem literally "years ago", a lot of creative energy in
OAM and PWs would not have been wasted.

Meanwhile we have the PW PID which seems to level the playing field across
the board as an OAM channel for PWs that can carry just about anything
without getting confused by already deployed ECMP mechanisms, we've also
given ECMP a lot of thought and an approach is documented in 17fec-cv for
the LDP layer. IMHO just about everything on the table at this point has
taken ECMP into account or at least ECMP as well as it is "commonly"
understood at this point.

I'm curious, is the ECMP that must be supported exclusively your
implementation? T'would be nice if the vendors who've deployed ECMP
documented what they've done in sufficent detail such that we could all
innovate in this space and knew all variations we needed to comply with.
Normally defining data plane OAM requires an agreed characterization of the
data plane. The situation as it stands is intolerable.....

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Monday, November 17, 2003 8:51 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Allan, David [CAR:NS00:EXCH]; [email-masked]
> Subject: RE: on the mpls oam framework 
> 
> 
> 
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On Behalf
> >Of Curtis Villamizar
> >Sent: Sunday, November 16, 2003 5:24 PM
> >To: [email-masked]
> >Cc: [email-masked]; [email-masked]; [email-masked]
> >Subject: Re: on the mpls oam framework 
> >
> >
> >
> >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:
> >> > 
> >> > > IMHO You are persisting in ignoring what you don't want to see.
> >> > 
> >> > 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.  As far as the OAM framework is 
> concerned, they are 
> >part of the architecture and widely deployed so they must be 
> supported 
> >by OAM tools.  It simply means that working with PHP and ECMP are 
> >requirements for OAM.
> 
> 	One thing that seems to be out of sight of this
> dicussion is that the OAM framework MUST provide a 
> framework that works based on the requirements stipulated
> in the MPLS OAM Requirements draft; it cannot make new things 
> up. There are a dozen operators that have officially provided 
> input into this document (and many more unofficially), so 
> I think it is a good idea to listen to these requirements. 
> Handling of ECMP is definitely specified in the aforementioned 
> draft.
> 
> >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.
> >
> >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.
> 	
> 	We already have:  draft-ietf-mpls-oam-requirements-02.txt
> 
> 	--Tom
> 
> 
> > 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.
> >
> >Curtis
> >
> >
> 
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 17 Nov 2003 10:08:56 -0500

>From: David Allan [mailto:[email-masked]] 
>Sent: Monday, November 17, 2003 9:17 AM
>To: [email-masked]'; [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>that there was a problem literally "years ago", a lot of 
>creative energy in OAM and PWs would not have been wasted.
	
	Sure, we can keep crying about the past, but I think
we should just move forward with what we have.

>implementation? 

	I would love for that to be the case. Great proposal! *)

> T'would be nice if the vendors who've deployed ECMP

	I do not believe that my algorithm(s) are documented anywhere,
nor do I think that Kireeti's, Curtis' or otherwise.  I think this 
is why tools/techniques we produce need to be flexible in this
area to support all types.  Throwing away what exists today is
not an option.

	--Tom

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Nov 2003 13:13:33 -0500

In message <[email-masked]>, "
> OAM and PWs would not have been wasted.

We been here before.  ECMP has been around in everything from IGPs to
BGP to MPLS.  In IGPs it goes back 15 years.  In BGP 10 years or
more.  In RSVP/TE it was implemented very early on and was no secret.
And ECMP has also been stated as a customer requirement for LDP,
implemented, and deployed there too.

> data plane. The situation as it stands is intolerable.....

There really is no secret to how ECMP is done.  There was discussion
on multipath in RFC2991 and RFC2992 and plenty of discussion on this
list and on PWE3.  The PWE3 architecuture
(draft-ietf-pwe3-arch-06.txt) might be insufficient for what you are
looking for because it just covers not breaking this functionality for
PW.  It does indicate that this ECMP stuff is a poorly guarded secret
at worst.

Its true that the only statement tying this to MPLS is "Some router
implementations also allow equal-cost multipath usage with RIP and
other routing protocols."  However, it is a very poorly kept industry
secret that every router from the PC-RT based NSF T1-NSS of late 1980s
vintage until now have used source/destination based hashing for IP
traffic no matter how it has been moved.  This includes concatonated
physical interfaces (a form of bundling), RSVP/TE from ingress, LDP,
and any form of RSVP/TE hierarchy (for example, LDP over RSVP/TE where
the underlying RSVP/TE uses multipath).

Currently draft-ietf-mpls-oam-requirements-02.txt references
draft-allan-mpls-loadbal-01.txt which has expired.  The problem may be
that draft-allan-mpls-loadbal-0x.txt doesn't reflect reality.  Recall
that the objections to this draft were because it did not cover
existing practice.  Perhaps we should start with a load balancing
internet-draft that referenced RFC2991 and RFC2992 and explicitly
referenced the definition of the PW PID (currently in
draft-ietf-pwe3-arch-06.txt).

Curtis