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

From: [email-masked]
Date: Mon, 31 Jul 2006 10:37:43 -0400 (EDT)

>I tend to agree with Tony that it's going to mean different things for
>different proposals, so we might just require that any proposal discuss
>how discontiguous deployments would work, and what the tradeoffs are for
>that specific proposal (?)....

Even if we require a "MUST be deployable in non-contiguous deployment",
I think there is value in requiring certain analysis for any proposed
solution.

Is that an OK thing to do in a protocol requirements document - require
that the solution description discuss certain things?

If it was OK, I'd like to have the solution discuss:

- the benefit to each island of non-continguous deployment to knowing
  security info related to another island of deployment (in some cases
  of security info, this will be obvious, in others it may require
  discussion of deployment scenarios, etc.)

- how security info would be communicated between islands

  - if in-band, the in-band mechanism and cost in terms of b/w, memory,
    processing, latency, yada, yada

  - if out-of-band, the out-of-band protocol and the intended operational
    use with particular focus on start-up conditions for router and for
    ISP peerings.

- a discussion of the dynamics of the system - how changes in security
  info or base routing information get communicated (that's kinda vague, but
  it is something I look for in solutions - and it's an issue more related
  to the communications than to non-contiguous deployment).

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Jul 2006 16:17:47 -0400

I agree with Sandy's suggestions re requiring an analysis of the 
benefits of non-contiguous deployment. I would add that we should 
look at the costs as well, and the issue of configuration complexity. 
For example, if configuration of routers to take advantage of 
non-contiguous deployment is very complex, then are we better off 
with non-contiguous deployment that causes the "islands" Sandy noted 
to just act as islands, vs. creating management-induced 
vulnerabilities?

Steve