[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