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

[Harald Tveit Alvestrand <[e-mail]>]

Marcus,

thanks for the follow-up!

--On 23. juli 2003 18:27 +0200 Marcus Brunner <[e-mail]> wrote:
>>
>> 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?

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.....

>> 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.

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.
>
> 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.

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

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