Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

[Danny McPherson <danny at tcb.net>]

On Apr 30, 2008, at 4:03 PM, John G. Scudder wrote:
> And did you think that client was behaving appropriately then?

No, neither did your current employer.  But the other vendor
pointed to the spec changes and said they were compliant and
the client needs to know it's a client and needs to drop the
extraneous updates.

I'd be keen on revamping 2796 again to remove that local
optimization, personally.  I'm no fan of expanding upon it.

> If so,
> why did you think it was OK for the client to violate the base spec?
> Also, you mentioned that your "real network" example was from ~10
> years ago, so while it's interesting... do you think such clients are
> still likely to exist *today*?

Depends on whether I think the spec change was
appropriate or not.  Again, local optimizations that
result in much more system-wide state I'm not a big
fan of.

> I guess different operators have different views about where in the
> optimization space they want to live.  For that matter, if the
> (redundant pair of)

If they're redundant, then there's dual the amount of
extraneous state, and they may still share a common
switched link layer or the like.

> RRs goes south, the PE's connectivity to the rest
> of the world is broken anyway, local connectivity is just a special
> case.  I can understand why the survival of that special case when the
> rest of the world is broken may not be seen as a deal-breaker.

Perhaps.  I wouldn't buy such a service from an operator
that designed their network in this manner, you might (although
I doubt it :-), but fair enough.

I believe folks that are implementing this may want to help
their customers understand this case, and I think the
draft would benefit from it's discussion as well.

-danny
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr