Subject: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Comments 1

From: Marcus Brunner <[email-masked]>
Date: Wed, 23 Jul 2003 18:27:47 +0200

See comments inline.

--On Donnerstag, 26. Juni 2003 21:31 -0700 Allison Mankin <[email-masked]> 
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 <[email-masked]>
> To: [email-masked]
> 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: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 24 Jul 2003 08:00:44 -0700

Marcus,

thanks for the follow-up!

--On 23. juli 2003 18:27 +0200 Marcus Brunner <[email-masked]> wrote:
> of the draft, therefore it went grammatically wrong. At this point in
> time, I think that the whole paragraph can be removed.
>

Do you use the distinction between "host to first router", "access network" 
and "core network" elsewhere in the document? I could find "access network" 
and "core network", but not "host to first router". Defining those terms is 
important, since different people get upset based on where you place the 
boundary. OTOH, "host to first router" is relatively easy to figure out.....

> something different that what is stated in the draft. Some people
> regarded the requirement as motherhood and apple pie anyway.

It's been one of the major hassles of RSVP deployment (from my far-away 
ivory tower, at least) that it never got around to actually discussing 
numbers when talking about scaling; the technology works fine (I think) in 
an enterprise context where the number of users has 4 or 5 digits, and the 
provisioning of the network is under centralized control; the hassles we 
have had involve trying to imagine the operation, economics and politics of 
deploying something at "Internet scale". Given that we've already got a lot 
of history here about discussion of scale, I think being explicit is good.
> system, where as salability is concerned more with the performance of it.

To my mind, scalability has two aspects:

- How far can you go?
- What happens when you hit the edge?

There was one IOS version (beta code, I think) many years ago that, when 
you started listening to multicast groups, fell over when you hit the limit 
of resources available for multicast state. That's the worst kind of not 
scaling. And the fear that there might be more bugs like this has been a 
major worry of people thinking about deploying multicast, and other 
protocols where they lumped issues under the "scaling" label.

Again - it's history that drives my worries.....

> Somebody from the WG has an idea how to resolve that?

Thanks for the feedback, and hope this is useful!

                      Harald

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 25 Jul 2003 15:55:32 +0200

--On Donnerstag, 24. Juli 2003 08:00 -0700 Harald Tveit Alvestrand 
<[email-masked]> wrote:

>>> First of all, the grammar is sufficiently convoluted that I have
>>> problems parsing it.
>>>
> Do you use the distinction between "host to first router", "access
> network" and "core network" elsewhere in the document? I could find
> "access network" and "core network", but not "host to first router".
> Defining those terms is important, since different people get upset based
> on where you place the boundary. OTOH, "host to first router" is
> relatively easy to figure out.....

The only implication we make with he term access network is that is nearer 
to the edge and relatively low capacity. The term access network is used 
another 3 times in the draft 2 times because of the bandwidth 
characteristics and once concerning security (controlling and charging for 
the access).

So think we should just make the definition clearer?

>
>>> 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....)
>>>
> numbers when talking about scaling; the technology works fine (I think)
> in an enterprise context where the number of users has 4 or 5 digits, and
> the provisioning of the network is under centralized control; the hassles
> we have had involve trying to imagine the operation, economics and
> politics of deploying something at "Internet scale". Given that we've
> already got a lot of history here about discussion of scale, I think
> being explicit is good.

Getting consensus is sometimes hard with being explicit.
I will try to get the text clearer here as well.

Thanks for the comments anyway.

Marcus

> you started listening to multicast groups, fell over when you hit the
> limit of resources available for multicast state. That's the worst kind
> of not scaling. And the fear that there might be more bugs like this has
> been a major worry of people thinking about deploying multicast, and
> other protocols where they lumped issues under the "scaling" label.
>

Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.