Re: [RPSEC] Discontiguous Deployment (Show of Hands)....

In message <20070228174125.E53EC3F443@pecan.tislabs.com>
Sandy Murphy writes:
>  
> I got to thinking about:
>  
> Tony Tauber said:
>  
> >>   o  In an environment where secured service is in the process of
> >>      being deplyed a mechanism MUST exist to support a transition
> >>      free of service interruption.
> >
> >I think the original bullet is about something else and still has
> >merit, but I like your addition.
>  
> If a secured service requires a change in the router software,
> would it not then require a service interrruption to upgrade the software?

Some routers can do a change in software without disruption.  For
routers that don't that shouldn't disqualify the protocol change.
Obviously no progress can be made without software changes.

> Is this stipulation intended to outlaw any and all in-band secured service?

No.  IMHO.

> Would a replacement for the TCP MD5 method, for example, be outlawed?

In that case BGP gracefull restart might be suggested as a means of
easing the transition.  Again, the absense of gracefull restart in an
implementation or failure to use it shouldn't disqualify the protocol
extension.

> Just how broad a "free of service interruption" requirement is this?
>  
> --Sandy

Do it right and it could be completely free of service interruption.
I think the intent is to completely disallow "flag day" changes that
require simultaneious change to multiple routers that can't be
accomplished in a reasonable amount of time and to discourage changes
that require taking one thing down before bringing another up in a way
that can't be done at all without disruption.  For BGP session
restarts gracefull restart should be assumed.

But then again, I'm just lurking so I could be clueless (again? :).

Does the above statement need this level of clarification in the
document in your opinion?  [Assuming I've got it mostly right here.]

Curtis

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec