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

[Marcus Brunner <[e-mail]>]

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

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

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

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


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



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