Re: requirements draft revision

[Joe Abley <jabley-ietf@automagic.org>]

On Wed, Jun 27, 2001 at 09:50:20AM -0500, Brian E Carpenter wrote:
> My comments on the -01 draft (presumably you will post it officially?)

It is coming.

> You define the SHOULD/MUST/etc terminology but don't use it. I think this
> is important - some of the requirements should be SHOULDs and some of
> them must be MUSTs, but I don't think that is correct yet in the text.
> For example, imho 3.1.1 should be MUST, but it starts with a "should".
> I suggest a pass through the draft to clarify this everywhere.

Yes, thanks for reminding me. I will attempt to do that shortly.

> 3.1.1:
> 
> >    The multihoming architecture must accommodate (in the general case,
> >    issues of shared-fate notwithstanding) the following failure modes:
> 
> I don't find the parenthesis very clear. Suggestion:
>   (in general, disregarding the survival of individual sessions 
>   as covered by section 3.1.6)

That's not what I meant. An example of what I was trying to convey is
that to protect against local-loop failure, it is reasonable to order
two access circuits. However, if those two access circuits happen to
run through the same building access, over the same fibre, through
the same SONET mux, etc, etc, then in practice you may not be protecting
yourself from many of the likely reasons for failure. Those two circuits
have "shared fate".

> 3.1.6:
> 
> >    Multihoming solutions must provide re-homing transparency for
> >    transport-layer protocols; 
> 
> I think we have to be more precise. Firstly it isn't the protocol that
> survives, it's the session. Secondly, does this include UDP? Suggestion:
> 
>    Multihoming solutions must provide re-homing transparency for
>    transport-layer sessions, including protocols such as
>    TCP and SCTP, and purely stateless protocols built on UDP.

That certainly makes things clearer.

> [actually what about applications built on raw IP??]

If we put a re-homing transparency requirement in for those, aren't we
mandating that end-point IP addresses must survive through a re-homing?
Doesn't that bring us back to exactly where we are today?

Thanks for the feedback!


Joe