[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: requirements draft revision
Joe Abley wrote:
>
> 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.
Yes, in fact it came, thanks.
>
> > 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".
OK, so your phrase does need clarifying.
>
> > 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?
I think so. So it should be stated as a non-requirement.
Brian