RE: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Commen ts 1

["Hancock, Robert" <[e-mail]>]

hi,

These aren't easy.

My view is that the two 'parts of the network' paragraphs (the one 
Harald quotes and the one before it) could be safely removed.

The general point about being able to adapt to deployment conditions 
is made at the very start of section 5; the rest of the document uses
the terms 'access' and 'core' in an informal (and probably self-explanatory)
way, and I don't see a need for a stricter definition. (Indeed, IIRC
Marcus made this point of deliberate vagueness very explicit when 
this 'parts of the network' issue came up in the Minneapolis WG meeting.)

(We could add a comment in the middle of the 2nd paragraph of section 5
that: We use the terms 'access' and 'core' informally in the discussion 
of some particular requirements to refer to deployment conditions where 
particular protocol attributes, especially performance characteristics, 
have special importance. Or something like that.)

==================================================

How to handle the scaling concern seems much harder. Part of the
problem is that the signalling protocols have to be capable of per-
microflow operation, and if network managers insist on trying to 
[ab]use them that way in the network core, there isn't much we can do
about it. In general, achieving most of what Harald refers to is a 
matter of using a scalable resource management architecture, and 
scalable protocol behaviour will largely follow from that. But the
resource management problem is out of scope for us anyway. In other
words, the requirement he suggests cannot be satisfied by NSIS, but
only by NSIS protocols supporting appropriate operational mechanisms
(which we don't know all of in the first place, in fact).

I can suggest 2 things:
a) Add some text to 5.5.1 to say something like 'In order to be useful
even in an environment where the use of signalling by hosts becomes
universal, NSIS protocols must allow for use at a level above 
that of individual end-to-end flows (ref. 5.2.4 and 5.6.1).'
b) Reinforce a little bit 5.5.4 to say that performance should
degrade gracefully rather than catastrophically under overload
conditions. (Which is actually something we are worrying about
at the moment anyway.)

Maybe these are over-specific or over-detailed.

cheers,

robert h.

> -----Original Message-----
> From: Marcus Brunner [mailto:[e-mail]]
> Sent: Wednesday, July 23, 2003 17:28
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt 
> - Comments
> 1
> 
> 
> See comments inline.
> 
> --On Donnerstag, 26. Juni 2003 21:31 -0700 Allison Mankin 
> <[e-mail]> 
> wrote:
> 
> > The IESG reviewed the NSIS Requirements.  There was some 
> concern over
> > the readability.  In addition, there were a few technical 
> comments that
> > should be addressed.  Here are Harald Alvestrand's.
> >
> > Allison
> >
> > ------- Forwarded Message
> >
> >
> > Date: Thu, 26 Jun 2003 08:35:22 -0700
> > From: Harald Tveit Alvestrand <[e-mail]>
> > To: [e-mail]
> > Subject: A couple of comments on draft-ietf-nsis-req
> >
> >
> > This section, from the start of section 5, worries me:
> >
> >
> >    The parts of the networks we differentiate are the host-to-first
> >    router, the access network, and the core network. The 
> host to first
> >    router part includes all the layer 2 technologies to 
> access to the
> >    Internet. This part of the division is especially 
> informal and may
> >    incorporate several access segments. In many cases, there is an
> >    application and/or user running on the host initiating signaling.
> >    The access network can be characterized by low capacity links,
> >    medium speed IP processing capabilities, and it might 
> consist of a
> >    complete layer 2 network as well. The core network 
> characteristics
> >    include high-speed forwarding capacities and inter-domain issues.
> >    These divisions between network types are not strict and do not
> >    appear in all networks, but where they do exist they may 
> influence
> >    signaling requirements and will be highlighted as necessary.
> >
> > First of all, the grammar is sufficiently convoluted that I 
> have problems
> > parsing it.
> >
> > Second, I have definitional problems.
> >
> > I have problems imagining how an access network can work if 
> it does NOT
> > contain a "complete layer 2 network" - after all, a link 
> is, in its way,
> > a  layer 2 network. OTOH, I don't think GSM/GPRS can fairly 
> be called a
> > "layer  2 network" - it's more complex than that - but it's 
> definitely
> > being used  as an access network.
> >
> > The sentence "host to first router part includes all the layer 2
> > technologies to access to the Internet" does not parse, and 
> makes the
> > definition only make sense when the first router is connected to the
> > Internet - I don't think that was intended.
> >
> > Since this paragraph is key to the overall architectural 
> constraints, I
> > think it's rather important to make it crystal clear.
> >
> 
> Actually, I don't think the paragraph is that much a key to the whole 
> architecture. However in the consensus finding phase it help 
> to make a 
> number of people happy. It has been heavily discussed during 
> the lifetime 
> of the draft, therefore it went grammatically wrong. At this 
> point in time, 
> I think that the whole paragraph can be removed.
> 
> Anybody objecting to this?
> 
> 
> > Section 5.5.1 on scalability worries me a lot, because it 
> uses "scalable"
> > without referring to a scale; while it may be appropriate 
> to "scale" an
> > end-system-to-first-router protocol to 10.000 users and say "good
> > enough",  I think core routers have scalability 
> requirements to millions
> > of active  participants (which argues for them not having 
> to see their
> > state....)
> >
> > I would like to see some hand-wringing here like:
> >
> > "The NSIS protocols MUST be scalable up to the level of 
> ubiquity - that
> > is,  if every end-user on the network uses NSIS functions, 
> the system
> > MUST NOT  be brought to a catastrophic failure, but continue to give
> > service  appropriate to the resources available."
> >
> > There might be more than this, but this is at least worrying.....
> 
> I understand the worry, but your proposal does at least for 
> me not say 
> something different that what is stated in the draft. Some 
> people regarded 
> the requirement as motherhood and apple pie anyway.
> 
> Actually, what I think you are referring to is the robustness of the 
> system, where as salability is concerned more with the 
> performance of it.
> 
> Somebody from the WG has an idea how to resolve that?
> 
> Marcus
> 
> --------------------------------------
> Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [e-mail]
> WWW:    http://www.ccrle.nec.de/
> Phone: [phone]
> Mobile: [phone]
> personal home page: http://www.brubers.org/marcus
> 
> 
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis