Subject: [Anima] GDNP open issues (draft-carpenter-anima-gdn-protocol-01)

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2015 13:56:26 +1300

Hi,

We'd like to get a sense of where to focus discussion leading
up to Dallas. There are a lot of open issues in the -01 draft.
Below I've extracted (and shortened) some that seem most important
to me personally. I've re-ordered them a bit too. Please send
feedback (maybe set the Subject of your message accordingly).

Of course this list is not exclusive, and comments on any aspect
of the draft are welcome.

  o  DTLS or TLS vs built-in security mechanism. The current
     approach requires expensive asymmetric cryptographic
     calculations for every message. (D)TLS has startup
     overheads but cheaper crypto per message.

  o  We mention convergence mechanisms and mechanisms to avoid
     loop dependencies. These issues need more work.

  o  Is it reasonable to consider that a Discovery Objective is really
     just a set of specific Negotiation and/or Synchronization
     Objectives?

  o  Would a DISCOVERY(ANY) mechanism be useful during bootstrapping?

  o  Would it be reasonable to allow an unsolicited Response message
     with Discovery Objective content, to speed up discovery during
     bootstrapping?

  o  Should we consider a distributed or centralised DNS-like approach
     to discovery (after the initial discovery needed for
     bootstrapping)?

  o  DoS Attack Protection needs work. Ideas welcome.

  o  Alternatives to TLV format.  It may be useful to provide a method
     of carrying negotiation/synch objectives in pre-existing formats.

  o  UDP vs TCP: If messages exceed a reasonable MTU, a TCP mode
     may be necessary.

Regards,
    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 27 Jan 2015 06:15:31 +0000

>  o  UDP vs TCP: If messages exceed a reasonable MTU, a TCP mode

For me, discovery should be UDP giving the fact that most of message exchanging would be very short. I am not sure about synchronization and negotiation. TCP is certainly more reliable, but it requests more complicated handshake before the peers can actually exchange information. One more consideration is to mix UDP/TCP into a single protocol design may be creating unnecessary complexity and confusion. Also, rapid discovery process is actually doing part of negotiation. It may not be able to separate these process totally.

If we consider security/authentication information in the messages, it is possible to exceed MTU. But why this is necessary for choosing TCP? UDP messages can also be fragmented.

Best regards,

Sheng

>Regards,
>    Brian
>
>_______________________________________________
>Anima mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/anima

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 27 Jan 2015 06:28:04 +0000

>     loop dependencies. These issues need more work.

Personally, I don't think we could complete these mechanisms to avoid loop dependencies. These mechanisms are specific with certain autonomic network agents, who use GDNP to make decisions. On another side, a generic mechanism to detect looped message may be needed. Also some guidance for autonomic network agents design on how to avoid loop dependencies would be great. But I am not sure it is in the scope of GDNP design document. It may worth a separated document, I guess.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 27 Jan 2015 07:03:29 +0000

>  o  Would a DISCOVERY(ANY) mechanism be useful during bootstrapping?

This depends on a) how many are ANY, b) how many counterpart may be discovered.

If ANY is less than twenty or thirty, it may not be a very big impact. But if ANY is more than a hundred, it may be too much for both the autonomic network and the initiated node. My guess is we could not limit how many objectives may be developed in the future.

The initiated may not be able to control how many counterpart to be discovered. If the autonomic network itself is a large-scale network, such discovery (ANY) may have message bust issue. However, this may not be a big issue, if there are autonomic partition mechanisms in such large scale autonomic network.

Best regards,

Sheng

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 27 Jan 2015 09:16:57 +0200

> For me, discovery should be UDP giving the fact that most of message exchanging would be very short. I am not sure about synchronization and negotiation. TCP is certainly more reliable, but it requ…

Discovery (assuming you want to do multicast) has to be UDP.

It depends on traffic amounts I guess; TCP does give you lots of things relatively for free, and e.g. implementation-wise TLS is more mature and common than DTLS. If you guess >MTU sized traffic is the norm, I would go with TCP for heavy lifting anyway (see below).

> If we consider security/authentication information in the messages, it is possible to exceed MTU. But why this is necessary for choosing TCP? UDP messages can also be fragmented.

If you cross hops or admin boundaries, you will potentially run at ‘we eat UDP fragments’ firewalls like the IKE people did. There is now ‘we do our own fragmentation’ IKE draft/RFC (I cannot remember the status). Given nodes on the path that eat ICMP PMTU messages, you wind up having to send things at minimum MTU UDP if you want to make sure they make it. And that’s ugly. 

Cheers,

-Markus

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 27 Jan 2015 07:43:59 +0000

>> For me, discovery should be UDP giving the fact that most of message
>>exchanging would be very short. I am not sure about synchronization and
>>negotiation. TCP is certainly more reliable, but it requests more complicated
>>handshake before the peers can actually exchange information. One more
>>consideration is to mix UDP/TCP into a single protocol design may be creating
>>unnecessary complexity and confusion. Also, rapid discovery process is
>>actually doing part of negotiation. It may not be able to separate these
>>process totally.
>

Agree. Discovery means unknown recipients. So multicast is necessary.

>It depends on traffic amounts I guess;

Discovery should be a set of short communications, which of them have only one or two message. So UDP looks better.

Synchronization is also a set of short communications, but between certain pairs. So UDP or long-live TCP session could work.

Negotiation may be longer communications. TCP may be better.

>TCP does give you lots of things
>relatively for free, and e.g. implementation-wise TLS is more mature and
>common than DTLS. If you guess >MTU sized traffic is the norm, I would go
>with TCP for heavy lifting anyway (see below).

This lead to another topic: whether discovery could be less security. 

>> If we consider security/authentication information in the messages, it is
>possible to exceed MTU. But why this is necessary for choosing TCP? UDP
>messages can also be fragmented.
>
>If you cross hops or admin boundaries, you will potentially run at ‘we eat
>UDP fragments’ firewalls like the IKE people did. There is now ‘we do our
>own fragmentation’ IKE draft/RFC (I cannot remember the status). Given
>nodes on the path that eat ICMP PMTU messages, you wind up having to send
>things at minimum MTU UDP if you want to make sure they make it. And
>that’s ugly.

It looks we are handing into a new situation - mix UDP/TCP into a single protocol design. That's ok, LDP discovery runs on UDP port 646 and the session is built on TCP.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 27 Jan 2015 07:43:46 +0000

>     of carrying negotiation/synch objectives in pre-existing formats.

A tag-based description format may be a good choice (not necessary to be xml). It would firstly save the type resource. It would also give much more flexibility and extensibility. One example could be like:

Type 20 (it has to be contained into an assigned TLV if we want it to be co-exist with other TLV, rather than only format)

<objective>
   <type>prefix< type>
   <prefix length>32</prefix length>
   <value>xxxx:xxxx:: </value>
</objective>

The objective could easily be extended to other types in such format.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 27 Jan 2015 08:14:12 +0000

>     just a set of specific Negotiation and/or Synchronization

I am not sure why we need to distinguish Discovery Objective, Negotiation Objective and Synchronization Objective. For me, all these objectives are equal. They are management objectives. They are the objectives autonomic nodes need to manage. However, in different content, the objective may contain different contents or similar content have different meaning. For instance, Discovery may just need the objective type to discovery right counterpart, synchronization may just provide a status of the objective, negotiation request may contain a request preference for the objective, negotiation response may contain a reject for the objective or assigned resource or further negotiation hints for the objective 

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 27 Jan 2015 08:59:03 +0000

>     to discovery (after the initial discovery needed for

I read out two core meanings from the above words: a) registration mechanism b) iterative resolving mechanism. This looks like a reasonable alternative for multicast message based discovery mechanism. However, t I have a primary concern: maintenance, this mechanism is stateful, it requests resource to main states, while multicast message based discovery is stateless. When the autonomic network is become big, the maintenance and resolve may take a lot resource. Of course, multicast message based discovery may create more messages. More concerns may raise if we decide to explore/design this mechanism further.

Best regards,

Sheng

---

From: Duzongpeng <[email-masked]>
Date: Tue, 27 Jan 2015 09:08:20 +0000

Hi Brian:

  I agree with that the Auto-Discovery mechanism is essential in the autonomic network.

  On one hand, a new device should introduce itself; on the other hand, the new device needs to know about the neighbor, network, and service information.

  When thinking about it further, I think that in this DISCOVERY mechanism, self-description and self-advertisement of the devices in the network is an important aspect, and a standard format of expression is helpful to let the devices know the capabilities of each other.

Best regards,

Zongpeng Du

-----邮件原件-----
发件人: Sheng Jiang 
发送时间: 2015年1月27日 15:03
收件人: Brian E Carpenter; [email-masked]
抄送: Duzongpeng
主题: DISCOVERY(ANY) mechanism was: RE: [Anima] GDNP open issues (draft-carpenter-anima-gdn-protocol-01)

Best regards,

Sheng

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 27 Jan 2015 10:40:42 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Tuesday, January 27, 2015 4:14 PM
> To: Brian E Carpenter; [email-masked]
> Subject: [Anima] objectives was: RE: GDNP open issues
> (draft-carpenter-anima-gdn-protocol-01)
> 
> I am not sure why we need to distinguish Discovery Objective, Negotiation
> Objective and Synchronization Objective. For me, all these objectives are
> equal. They are management objectives. They are the objectives autonomic
> nodes need to manage. However, in different content, the objective may
> contain different contents or similar content have different meaning. For
> instance, Discovery may just need the objective type to discovery right
> counterpart, synchronization may just provide a status of the objective,
> negotiation request may contain a request preference for the objective,
> negotiation response may contain a reject for the objective or assigned
> resource or further negotiation hints for the objective
[Bing] I think there might be two possible designs:
1. As Sheng said above, we only model the objectives in one dimension. All the objectives are a set of flat management functions/features. No distinguish between Discovery/Negotiation/Sync objectives.
2. We make Discovery/Negotiation/Sync focus on different aspects, e.g.:
- Discovery Objectives represent "who"
- Negotiation Objectives represent "what to do"; they could be folded into one Discovery Objective, or they're just two dimensions.
- Sync content could be a combination of the above two kinds of objectives

No.1 is obviously simpler and clearer; No.2 is complicated but might be more capable to model the complex management objectives.
Currently, I can't figure out whether No.1 could fit the requirements. What are your thoughts?

Best regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jan 2015 07:52:52 +1300

> It looks we are handing into a new situation - mix UDP/TCP into a single protocol design. That's ok, LDP discovery runs on UDP port 646 and the session is built on TCP.

Apart from the problems with fragmentation and PMTUD sometimes failing
(which *might* be non-problems within a single administrative domain),
there is an overhead cost for fragmentation & reassembly. I'm wondering
whether anyone has studied that cost vs the overhead of TCP for a fairly
short communication.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jan 2015 07:59:54 +1300

> Personally, I don't think we could complete these mechanisms to avoid loop dependencies. These mechanisms are specific with certain autonomic network agents, who use GDNP to make decisions. On anot…

Well, we do need to add a section setting out general guidelines for the
definition of negotiation objectives. Mechanisms to guarantee convergence
should probably be mentioned there.

Maybe we need to add a countdown field (like a TTL) to each negotiation.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jan 2015 08:13:33 +1300

> Currently, I can't figure out whether No.1 could fit the requirements. What are your thoughts?

Well, first I am happy to see your opinion since I have been a bit puzzled
about this distinction from the beginning when I saw your initial design :-).

Yes, I agree with No. 1 except for one aspect: if there is a set of objectives
that always belong together (let's say IPv6 prefix and next-hop router,
to invent a possibly controveersial example). If I discover a counterpart
for assigning an IPv6 prefix, it would be pointless to then discover
a counterpart for indicating a next-hop router. It must be the same
counterpart. So we have two solutions:

A) Discover "assign IPv6 prefix" only, and use the result for both objectives.
B) Discover "assign IPv6 prefix and indicate next-hop router", in other
words a discovery objective that covers both negotiation objectives.

If you took the third solution:

C) Discover "assign IPv6 prefix" and then discover "indicate next-hop router"

there would be a problem if you got two different responses.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 28 Jan 2015 00:44:01 +0000

>1. As Sheng said above, we only model the objectives in one dimension. All
>the objectives are a set of flat management functions/features. No
>distinguish between Discovery/Negotiation/Sync objectives.
>- Negotiation Objectives represent "what to do"; they could be folded into
>one Discovery Objective, or they're just two dimensions.

One issue for the above #2 design is whether autonomic node can learn capabilities from "who". This requires explicit definitions, maybe standards. I am not sure it is feasible to unified the definitions, giving a) a devices may be multiple functions, b) different implementation for the same function among different vendors. This may also have some extensibility issue: router type 1 may first includes function a, b, c; later if function d is added into router type 1; in practice, the node would confuse when function d is available when it discovery a router type 1 device.

Best regards,

Sheng

>No.1 is obviously simpler and clearer; No.2 is complicated but might be more
>capable to model the complex management objectives.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 28 Jan 2015 00:52:51 +0000

>> No.1 is obviously simpler and clearer; No.2 is complicated but might be
>more capable to model the complex management objectives.

Hi, Brian,

I share the concern for above solution C. If two objectives are logically associated with each other, they should be grouped together, certainly. However, we need to be very careful to group loose-relation objectives together, it may give up unnecessary complexity. In other email, I also express my concern that non-standard role/group may not be efficient to discovery functions. So, I would recommend solution A, but also including to define a set of groups, each of which contains a set of associated functions.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 28 Jan 2015 00:59:26 +0000

>> Personally, I don't think we could complete these mechanisms to avoid loop
>dependencies. These mechanisms are specific with certain autonomic
>network agents, who use GDNP to make decisions. On another side, a generic
>mechanism to detect looped message may be needed. Also some guidance
>for autonomic network agents design on how to avoid loop dependencies
>would be great. But I am not sure it is in the scope of GDNP design document.
>It may worth a separated document, I guess.
>

This sounds a reasonable design. :)

Best regards,

Sheng

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Wed, 28 Jan 2015 03:06:58 +0000

Hi Brian 
For my opinion, I don't think it is reasonable to allow an unsolicited Response message in Discovery process. 
It may increase extra traffic and the content in unsolicited Response message may not be exactly what the counterpart want.
So it may not speed up the discovery process. Another potential issues is that the Discovery initiator may be subjected to Dos attack.
But I think it is reasonable to design unsolicited Response message in Synchronization process to synchronize the status of the objective since the status of counterpart had been changed.

Cheers
Yu

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, January 27, 2015 8:56 AM
To: [email-masked]
Subject: [Anima] GDNP open issues (draft-carpenter-anima-gdn-protocol-01)

Hi,

We'd like to get a sense of where to focus discussion leading up to Dallas. There are a lot of open issues in the -01 draft.
Below I've extracted (and shortened) some that seem most important to me personally. I've re-ordered them a bit too. Please send feedback (maybe set the Subject of your message accordingly).

Of course this list is not exclusive, and comments on any aspect of the draft are welcome.

Regards,
    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 28 Jan 2015 06:01:36 +0000

>It may increase extra traffic and the content in unsolicited Response message
>may not be exactly what the counterpart want.

Hi, Yu,

When discussion unsolicited Response message, it is based on there are some mechanism on the autonomic network node has some hints to predict the counterpart wants the objective in the message. Some example, could be based on previous discovery message or a current discovery message that tries to discover an associated objective.

So, Brian, I guess Yu's message implied a suggestion: you may need to first describe a suitable requirement/scenario/use case. Without it, we may not be able to validate the design.

Best regards,

Sheng

>So it may not speed up the discovery process. Another potential issues is that
>the Discovery initiator may be subjected to Dos attack.
>But I think it is reasonable to design unsolicited Response message in
>Synchronization process to synchronize the status of the objective since the
>status of counterpart had been changed.
>
>Cheers
>Yu
>
>We'd like to get a sense of where to focus discussion leading up to Dallas.
>There are a lot of open issues in the -01 draft.
>Below I've extracted (and shortened) some that seem most important to me
>personally. I've re-ordered them a bit too. Please send feedback (maybe set
>the Subject of your message accordingly).
>

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Thu, 29 Jan 2015 02:09:54 +0000

Hi Sheng,

>So, Brian, I guess Yu's message implied a suggestion: you may need to first describe a suitable requirement/scenario/use case. Without it, we may not be able to validate the design.

Yes, a description of the requirement/scenario/use case will make sense.

Thanks
Yu

-----Original Message-----
From: Sheng Jiang 
Sent: Wednesday, January 28, 2015 2:02 PM
To: Fuyu (Eleven); Brian E Carpenter
Cc: [email-masked]
Subject: RE: [Anima] unsolicited Response message//RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01)

>>It may increase extra traffic and the content in unsolicited Response 
>>message may not be exactly what the counterpart want.

>>So it may not speed up the discovery process. Another potential issues 
>>is that the Discovery initiator may be subjected to Dos attack.
>>Synchronization process to synchronize the status of the objective 
>>since the status of counterpart had been changed.
>
>>Cheers
>>Yu
>
>Below I've extracted (and shortened) some that seem most important to 
>me personally. I've re-ordered them a bit too. Please send feedback 
>(maybe set the Subject of your message accordingly).
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jan 2015 16:58:46 +1300

> Yes, a description of the requirement/scenario/use case will make sense.

It would have to be a negotiation objective that a majority of nodes
will want to negotiate, to justify an unsolicited broadcast. And I'm
not sure I have an eaxmple for that. Any ideas?

  Brian

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Fri, 30 Jan 2015 07:28:13 +0000

Hi Brian,

For example, the autonomic network node sends a discovery message try to discover the objective A. The counterpart responds it and then sends an unsolicited Response message including an objective B which is related to the objective A.  
The objective B and the objective A have some relationship.

Cheers
Yu

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, January 29, 2015 11:59 AM
To: Fuyu (Eleven); Sheng Jiang
Cc: [email-masked]
Subject: Re: [Anima] unsolicited Response message//RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01)

> Yes, a description of the requirement/scenario/use case will make sense.

It would have to be a negotiation objective that a majority of nodes will want to negotiate, to justify an unsolicited broadcast. And I'm not sure I have an eaxmple for that. Any ideas?

  Brian

> Subject: RE: [Anima] unsolicited Response message//RE: GDNP open 
> issues (draft-carpenter-anima-gdn-protocol-01)
> 
>>> For my opinion, I don't think it is reasonable to allow an 
>>> unsolicited Response message in Discovery process.
>>> It may increase extra traffic and the content in unsolicited 
>>> Response message may not be exactly what the counterpart want.
> 
>> Hi, Yu,
> 
>>> So it may not speed up the discovery process. Another potential 
>>> issues is that the Discovery initiator may be subjected to Dos attack.
>>> But I think it is reasonable to design unsolicited Response message 
>>> in Synchronization process to synchronize the status of the 
>>> objective since the status of counterpart had been changed.
>>
>>> Cheers
>>> Yu
>>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jan 2015 19:49:06 -0500

> If ANY is less than twenty or thirty, it may not be a very big
    > impact. But if ANY is more than a hundred, it may be too much for both
    > the autonomic network and the initiated node. My guess is we could not
    > limit how many objectives may be developed in the future.

I'm confused in this thread if the cardinality we are talking about is the
number of objectives,or the number of respondants.

If we are talking about how many peers there might be, then I wonder how many
links are actually natively multicast.  We don't have coax and ethernet hubs
anymore, so a device (L3-aware L2-switch) is always involved in multicasting
among a network.  If that device speaks GNDP, then the LAN only has two ends.

While there likely are lots of L2 switches that won't speak GNDP, I would
think that where this is first deployed, in operator and backbone DC
networks, that this won't be the case.   Even modern wifi
is a star-configuration with MIMO antenna, etc.

(this scenario is not dissimilar from CDP/LLDP)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Duzongpeng <[email-masked]>
Date: Sat, 31 Jan 2015 03:34:48 +0000

Hi Michael:

    In my understanding, Sheng is talking about the number of objectives, and you are talking about the number of respondents.

  	Some other comments here. 
The objectives needed to be broadcasted can be further classified.
	1. in size, maybe some key elements are short and do not occupied too much bandwidth, but others not
	2. in frequency, maybe some objectives are needed to be updated frequently, but others not
	3. in importance, it is impossible to always broadcast everything, and some essential objectives should be identified
	...

Best regards,

Zongpeng Du

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Saturday, January 31, 2015 8:49 AM
To: [email-masked]
Subject: Re: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01)

    > limit how many objectives may be developed in the future.

I'm confused in this thread if the cardinality we are talking about is the number of objectives,or the number of respondants.

If we are talking about how many peers there might be, then I wonder how many links are actually natively multicast.  We don't have coax and ethernet hubs anymore, so a device (L3-aware L2-switch) is always involved in multicasting among a network.  If that device speaks GNDP, then the LAN only has two ends.

While there likely are lots of L2 switches that won't speak GNDP, I would think that where this is first deployed, in operator and backbone DC
networks, that this won't be the case.   Even modern wifi
is a star-configuration with MIMO antenna, etc.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-