Re: [OPSAWG] Negotiation replacing configuration

My - strictly personal - take (but I’m completely derailing the discussion here) would be to extend ICMP and create a path MTU message equivalent for throughput. Something with an optional solicitation message (could be ICMP ping with special code), and a reply along the lines of an ICMP  type 3, code 4 (‘packet too big’) message. When TCP on a host, or a router in general, thinks that things are going too slow, he’ll send one of those. They could also be sent back unsolicited in the way that packet too big messages are usually sent. The added benefit would be that routers along the path benefit from the information, and re-think their routes.

Sincerely,

KJ

On 03 Feb 2014, at 20:08, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Kees-Jan,
> 
> Good comments, thanks...
> 
> On 04/02/2014 04:24, Kees-Jan Hermans wrote:
>> Personal first impressions:
>> 
>> - Any tool that allows for the automatic configuration of devices wrt their routes, is also a tool for a DOS attack. You notice this, and that it should only run in 'trust relationships’. That’s good, but at the moment, the internet has scarce support for trust relationships.
> 
> One aspect is that such a protocol would only be used within a
> well-defined administrative boundary, so keeping an external
> DOS attack out is probably possible. An internally generated DOS
> attack will be harder to block, especially if it attacks the
> authentication of the protocol itself.
> 
>> - Negotiation usually implies multiple messages in a tight, ordered sequence. This doesn’t necessarily do well on unstable, mobile networks where messages may get lost, requiring time-consuming re-negotiation.
> 
> Good point. But p2p routing for mobiles has a similar problem;
> we need to look at how MANET handles this.
> 
>> - When you say ‘XML’, I say: needless complexity that runs afoul of what most small devices can or should have to handle. You notice this too, fortunately. Only too glad you didn’t go for TCP ;-)
>> 
>> - I wonder about using multicast. Doesn’t that create a chicken-and-egg problem (as the multicast configuration may be part of what we’re trying to configure about a router)? Also: packet storms.
> 
> Yes, that needs careful thought.
> 
>   Brian
> 
>> KJ
>> 
>> On 29 Jan 2014, at 01:04, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> I'm a bit surprised at the silence on this. After all, we
>>> are suggesting a fairly radical change of approach: from
>>> centrally-driven configuration of devices to peer negotiation
>>> between devices. In this WG we'd like to get feedback on
>>> the problem statement based on real experience, since the
>>> NMRG discussion is more likely to be theoretical.
>>> Also, is our summary of existing protocols accurate?
>>> 
>>>   Brian
>>> 
>>> -------- Original Message --------
>>> Subject: I-D Action: draft-jiang-config-negotiation-ps-02.txt
>>> Date: Sat, 18 Jan 2014 11:23:25 -0800
>>> From: internet-drafts@ietf.org
>>> Reply-To: internet-drafts@ietf.org
>>> To: i-d-announce@ietf.org
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> 
>>> 
>>>       Title           : Network Configuration Negotiation Problem Statement and Requirements
>>>       Authors         : Sheng Jiang
>>>                         Yuanbin Yin
>>>                         Brian Carpenter
>>> 	Filename        : draft-jiang-config-negotiation-ps-02.txt
>>> 	Pages           : 14
>>> 	Date            : 2014-01-18
>>> 
>>> Abstract:
>>>  This document describes a problem statement and general requirements
>>>  for distributed autonomous configuration of multiple aspects of
>>>  networks, in particular carrier networks.  The basic model is that
>>>  network elements need to negotiate configuration settings with each
>>>  other to meet overall goals.  The document describes a generic
>>>  negotiation behavior model.  The document also reviews whether
>>>  existing management and configuration protocols may be suitable for
>>>  autonomic networks.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-jiang-config-negotiation-ps-02
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>> 
>>> 
>>> -- 
>>> Regards
>>>  Brian Carpenter
>>>  http://orcid.org/0000-0001-7924-6182
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OPSAWG mailing list
>>> OPSAWG@ietf.org
>>> https://www.ietf.org/mailman/listinfo/opsawg
>> 
>> 
> 