The MPLS WG Archive

[neil.2.harrison@bt.com]

Curtis,
<snipped>
> Maybe it is <in response to 'sounds like religion'>.  The IETF does not
like open ended protocol with no meas
> of rate limiting.  This is in support of stability.
> 
> Network stability is more important goal than measurement accuracy.
NH=> Totally agree....but I'd guess directing effort to future IGP changes
is probably more important than this area.
<snip>

>    3.3 All designs must scale readily to very many nodes per 
> site and to
>    many millions of sites.
NH=> So where did v4 come from then?  I jest, we all make errors of
judgement....repeating them though in full knowledge is not so clever
however (GMPLS).
> 
>    3.4 Performance and cost must be considered as well as 
> functionality.
NH=> I can hear eggs being sucked by grannie.  Our finance people will love
you Curtis for reminding me of this ;-)
> 
>    3.5 Keep it simple. When in doubt during design, choose 
> the simplest
>    solution.
NH=> Done exactly that.
> 
>    3.6 Modularity is good. If you can keep things separate, do so.
NH=> Done that.....although implied I guess, its a real pity it does go on
to specifically say 'avoid layer/plane violations so that protocols can be
added/changed/removed without cross layer/plane impact'. 
> 
>    3.7 In many cases it is better to adopt an almost complete solution
>    now, rather than to wait until a perfect solution can be found.
NH=> Done that (ignored LDP, though do have backwards compatible solution if
forced to go there, and still need more work on P flows....which I want to
keep simple, but I suspect people will want to measure many metrics....we
still need to have the debate on this).
> 
> If the design principles that have been used to build the Internet so
> far is a religion in your view, so be it.
NH=> So, seems we've passed then?

<snipping>
> 
> In the event of a fault, the return path should heal quickly.  The
> same should be true to the forward path.  Loss of a small number of
> pings should be noted, but not acted on.  The failure that we are
> trying to detect is persistent failure not transient loss.
NH=> Both can actually be important.  If you get lots of transient events
that is not good news either...esp if you have specific availability SLAs to
meet.  This one is actually really important when several operators are in
tandem.  Even this situation has been thought about and provided for in our
work.
<snipped to end>
regards, Neil