Subject: ND Option for NMS Discovery-//FW: New Version Notification for draft-liu-6man-nd-nms-discovery-00.txt

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 22 Oct 2013 07:46:27 +0000

Hi, Dear All

I submitted a new draft, which is regarding using ND option to let the devices learn NMS (Network Management System) server's address when they get online.

As we know, it is necessary for the devices in ISP networks to be managed by NMS (it might also necessary for some enterprise networks).
So there is a problem of how to discover the NMS server for the devices. The traditional methods are through pre/manual config or a dedicated logical management network through which the NMS could discover the new devices periodically. 

This draft proposes a new method for the devices to actively discover the NMS server. When a devices gets online, it could learn the NMS server's address from its neighbor through the ND option defined in this document. The idea is simple and easy to be implemented, it is a good leverage of IPv6 automatic features. And the author believes it is useful in some scenarios, especially for some zero-config technologies.

Your comments would be appreciated much.

Best regards,
Bing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 21, 2013 7:02 PM
To: Liubing (Leo)
Subject: New Version Notification for draft-liu-6man-nd-nms-discovery-00.txt

A new version of I-D, draft-liu-6man-nd-nms-discovery-00.txt
has been successfully submitted by Bing Liu and posted to the
IETF repository.

Filename:	 draft-liu-6man-nd-nms-discovery
Revision:	 00
Title:		 IPv6 ND Option for Network Management Server Discovery
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-liu-6man-nd-nms-discovery-00.txt
Status:          http://datatracker.ietf.org/doc/draft-liu-6man-nd-nms-discovery
Htmlized:        http://tools.ietf.org/html/draft-liu-6man-nd-nms-discovery-00

Abstract:
   This document introduces a mechanism for devices to actively learn
   the NMS server address from the neighbors through IPv6 ND protocol
   extension. It is a good leverage of IPv6 automatic features.

   This document only discusses problem/solution within the IPv6-only
   networks/plane.

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.

The IETF Secretariat

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 22 Oct 2013 10:15:54 +0200 (CEST)

> Your comments would be appreciated much.

We have posted a similar kind of draft in Netconf-WG:

http://datatracker.ietf.org/doc/draft-fa-netconf-dhcpv6-option

I think your suggestion lacks for instance what kind of transport should 
be used to connect to the NMS, what port, and what kind of services the 
NMS offers. I guess could be expressed in the URL field, so you expect 
this option to be broadcasted in multiples in case the network supports 
multiple different types of NMS and different transport methods?

My opinion that this information is better carried in DHCPv6 as opposed to 
in ND.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 22 Oct 2013 08:43:38 +0000

Hi, Mikael

Thanks for your quick comments. See inline.

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Tuesday, October 22, 2013 4:16 PM
> To: Liubing (Leo)
> Cc: 6man WG
> Subject: Re: ND Option for NMS Discovery-//FW: New Version Notification
> for draft-liu-6man-nd-nms-discovery-00.txt
> 
[Bing] Yes. The ND option is not intend to be only for some specific transport methods. In this -00 version, we want to emphasize a "neighbor-learning" approach based on ND protocol.
But I agree with you the transport/management methods need to be considered in the draft. Will do in the next version.

> My opinion that this information is better carried in DHCPv6 as opposed to
[Bing] I'm afraid I can't agree, some scenarios might not involve DHCP, e.g. in the core networks, but ND is always on in IPv6. If the neighbors already knew something, it is quite convenient to propagate the information through ND.
May I ask the specific reasons that you prefer DHCPv6 over ND?

Best regards,
Bing

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 22 Oct 2013 11:08:15 +0200 (CEST)

On Tue, 22 Oct 2013, Liubing (Leo) wrote:

> [Bing] I'm afraid I can't agree, some scenarios might not involve DHCP, 
> e.g. in the core networks, but ND is always on in IPv6. If the neighbors 
> already knew something, it is quite convenient to propagate the 
> information through ND.

Why stop here then, there are a lot of other things we could put into ND 
that would also be convenient?

> May I ask the specific reasons that you prefer DHCPv6 over ND?

Because before a router knows anything, it's a host, not a router. DHCPv6 
is a "host" protocol. It was designed to do these things. There is no 
reason a router can't use DHCP to aquire knowledge, it's done using for 
instance DHCPv6-PD. Doesn't matter if it's a core router or not.

DHCP is used when someone wants to know something, in ND/RA things are 
announced all the time, periodically. I don't think putting "everything" 
there is a good engineering solution. For better or for worse, we have the 
separation between ND/RA and DHCP for different things, and I think it 
should be continued.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 22 Oct 2013 10:00:22 +0000

> that would also be convenient?
[Bing] Let's go back to the specific NMS information, I think it is quite convenient to propagated between routers through ND. 

> instance DHCPv6-PD. Doesn't matter if it's a core router or not.
[Bing] The router surely could use DHCP. But it implies we need to add additional DHCP Server configurations to do this. This might more or less increase the management burden.

> there is a good engineering solution. 
[Bing] I agree never announcing "everything". But I think the NMS could be basic information that worth to be announced.
And we could also use RS/NS to pull the information from neighbors.

Best regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Oct 2013 09:47:30 +1300

As I said when commenting on the draft charter recently:

I think there's a missing goal, something like

 - Define relationship and boundary between DHCPv6-based and RA/ND-based
   host configuration mechanisms. (This is partly an operational topic, but
   it lies behind a whole bunch of discussions in various WGs).

Unless we get this settled as a general matter, the discussion below will
continue to occur every time an RA/ND extension or a routing-related
DHCPv6 option is proposed.

Regards
   Brian

On 22/10/2013 22:08, Mikael Abrahamsson wrote:
>> [Bing] I'm afraid I can't agree, some scenarios might not involve
>> DHCP, e.g. in the core networks, but ND is always on in IPv6. If the
>> neighbors already knew something, it is quite convenient to propagate
>> the information through ND.
> 
> Because before a router knows anything, it's a host, not a router.
> DHCPv6 is a "host" protocol. It was designed to do these things. There
> is no reason a router can't use DHCP to aquire knowledge, it's done
> using for instance DHCPv6-PD. Doesn't matter if it's a core router or not.
> 
> there is a good engineering solution. For better or for worse, we have
> the separation between ND/RA and DHCP for different things, and I think
> it should be continued.
>

---

From: Doug Barton <[email-masked]>
Date: Tue, 22 Oct 2013 14:03:36 -0700

> DHCPv6 option is proposed.

FWIW I agree that this is a good problem to solve, but it should 
probably be a separate document, shouldn't it? Not that I envy anyone 
taking it on, or that I am optimistic for consensus, but it IS a topic 
it would be nice to get resolved.

Doug

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 22 Oct 2013 23:26:23 +0200

On Tue, Oct 22, 2013 at 11:03 PM, Doug Barton <[email-masked]> wrote:
> FWIW I agree that this is a good problem to solve, but it should probably be
> a separate document, shouldn't it? Not that I envy anyone taking it on, or
> that I am optimistic for consensus, but it IS a topic it would be nice to
> get resolved.

I used to say we should keep them separate, not add things into DHCPv6
that ND does, and the other way around. And I still belive they're not
really part of the same domain, or use cases.

However, after trying to explain ND and DHCPv6 several times I have to
admit - it was, and still is a good idea, but it's too complicated.
And also, we can not continue to have this discussion every/every odd
year.

I am against adding more to ND, let's keep it clean and neat. But I'm
in favour of adding more into DHCPv6. We probably can get consensus on
changing thing this time around :)

If is a job for this document or not, no opinion yet.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 22 Oct 2013 16:38:19 -0500

> DHCPv6 option is proposed.
I think we should separate SLAAC and stateful address configuration with
DHCPv6 versus
RA options for routing as in RFC 4191.

Why? Because the former is already in the RFCs, RFC 4861 and RFC 3315 while
for the latter, the DHCP proposal did not go through.

For the latter, the issue is should we add new RA options?
My answer is we should, the last time this has been done was in RFC 6106.
When new needs come up, why not add new RA options?

Regards,

Behcet

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 23 Oct 2013 02:37:34 +0000

Dear all,
IMHO, it is related to http://datatracker.ietf.org/doc/draft-schoenw-opsawg-nm-dhc<http://datatracker.ietf.org/doc/draft-schoenw-opsawg-nm-dhc/>/
What do u think about this?

Thank you,
Tina

On Oct 22, 2013, at 2:39 PM, "Behcet Sarikaya" <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Oct 22, 2013 at 3:47 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
As I said when commenting on the draft charter recently:

I think we should separate SLAAC and stateful address configuration with DHCPv6 versus
RA options for routing as in RFC 4191.

Why? Because the former is already in the RFCs, RFC 4861 and RFC 3315 while for the latter, the DHCP proposal did not go through.

For the latter, the issue is should we add new RA options?
My answer is we should, the last time this has been done was in RFC 6106. When new needs come up, why not add new RA options?

Regards,

Behcet
Regards
   Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Oct 2013 05:44:51 +0200 (CEST)

> When new needs come up, why not add new RA options?

Of course we should add, it just depends on definition when it's "needed". 
Why not put NTP server in there? TFTP server? DNSSEC KSK bootstrapping? IP 
address for Facebook (everybody uses that, right?!).

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 23 Oct 2013 03:55:41 +0000

Hi, Tina & All

I think both your draft  http://datatracker.ietf.org/doc/draft-schoenw-opsawg-nm-dhc<http://datatracker.ietf.org/doc/draft-schoenw-opsawg-nm-dhc/>

and Mikael's draft: http://datatracker.ietf.org/doc/draft-fa-netconf-dhcpv6-option
are related.

For my own understanding, the two drafts are regarding specific NMS types/method, one is for SNMP the other is for Netconf.
The ND option document is intend to be a general usage, whatever the NMS is, when a device is getting online, the neighbors could tell it.

Regards,
Bing

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Wednesday, October 23, 2013 10:38 AM
To: <[email-masked]>
Cc: 6man WG
Subject: Re: Need for an overview [was ND Option for NMS Discovery-//FW: New Version Notification for draft-liu-6man-nd-nms-discovery-00.txt]

Dear all,

Thank you,
Tina

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Oct 2013 16:56:07 +1300

On 23/10/2013 16:44, Mikael Abrahamsson wrote:
> Of course we should add, it just depends on definition when it's
> "needed". Why not put NTP server in there? TFTP server? DNSSEC KSK
> bootstrapping? IP address for Facebook (everybody uses that, right?!).
> 

The problem is getting new options implemented and deployed.
RFC 6016 is hardly available, for example (see recent
discussion on the [email-masked] list).

I'm not saying the situation is any better with new DHCPv6 options,
but duplication of solutions definitely makes deployment harder.

   Brian

---

From: Doug Barton <[email-masked]>
Date: Wed, 23 Oct 2013 00:34:42 -0700

> really part of the same domain, or use cases.

In a sense I think you're right about them being different use cases, 
but keeping them totally separate isn't the right answer. "The market" 
has been asking for full-featured DHCPv6 basically since day 1. We still 
haven't delivered on that.

> changing thing this time around :)

One can only hope. :)

Doug

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 23 Oct 2013 09:48:39 +0200

> In a sense I think you're right about them being different use cases, but
> keeping them totally separate isn't the right answer. "The market" has been
> asking for full-featured DHCPv6 basically since day 1. We still haven't
> delivered on that.

I think it's time we give them full-featured DHCPv6.

>> changing thing this time around :)

let's give it a go? I know of other that also think it's about time to
get this done now.
I'm more than happy to discuss and help out with ideas, but I'm not
there yet that I can write drafts... sort of language has never been
one of my strongest side :(

--

---

From: Tom Taylor <[email-masked]>
Date: Wed, 23 Oct 2013 08:06:24 -0400

In fact, it addresses the bootstrapping problem first identified in 
draft-tsou-network-configuration-problem-statement and then in the 
ill-fated draft-ietf-opsawg-automated-network-configuration. Round and 
round we go!

Tom Taylor

> What do u think about this?
...

---

From: Brian Haberman <[email-masked]>
Date: Wed, 23 Oct 2013 08:43:39 -0400

Hi Brian,
     The re-chartering effort for 6man is really focused on making the
WG flexible enough to address these types of issues as they come up.
Given that flexibility, other ADs wanted to avoid having specific work
items listed in the *charter*.  Current work items can be easily
identified in the milestones.

      Given the above approach, I would suggest that convincing the WG
to adopt a draft focused on defining that relationship is the first
step.  If the WG adopts it, I would have no problems working with the
chairs to add it to the milestones.

Regards,
Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Oct 2013 02:13:34 +0900

> chairs to add it to the milestones.

I agree that we're about due to attempt to have this conversation again.
Who knows, now that we have more operational and deployment experience than
we did last time, the outcome might be different.

Rather than have an argument based on single use cases, what might be
useful is to start with a document that lists the basic technical
properties / semantics of the mechanisms themselves. For example:

RA option: sent by the router; requires no server; hard to relay / apply
policy; easy to update at any time, even if the original router has
crashed; scales with router CPU; shares fate with routing; supports merging
multiple sources of information.

Stateless DHCPv6 option: sent by a server; requires a server; easy to relay
/ apply policy; scales with server CPU (which can be better or worse than
router CPU depending on how many thousands/millions of clients you send to
a single server); very hard to update from network side; doesn't share fate
with routing; doesn't support merging multiple sources of information.

"We do it this way in IPv4" or "the market is asking for it" (which are
mostly, though perhaps not entirely, the same argument) would explicitly
not be a part of this document because they're not technical properties of
the protocols.

The hope would be that we don't fundamentally disagree on the properties of
the two provisioning protocols, only on which characteristics are more
important in which deployment scenarios. If that's true, and we were able
to agree on this document describing the properties, then we might later be
able to move towards deciding what kinds of options go into which protocol.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Oct 2013 08:15:52 +1300

Ack. By definition it's too late to do anything before Vancouver,
but I agree that a draft is needed. It's on my list...

Regards
   Brian

On 24/10/2013 06:13, Lorenzo Colitti wrote:
> ------------------------------------------------------------------------
>

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 24 Oct 2013 02:17:59 +0000

>Stateless DHCPv6 option: very hard to update from network side

Reply to this single point: we have identified this issue and  working on it. A new draft has been submitted to DHC WG and would be discussed in Vancouver

http://tools.ietf.org/html/draft-jiang-dhc-stateless-reconfiguration

Best regards,

Sheng

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Thursday, October 24, 2013 1:14 AM
To: Brian Haberman
Cc: IETF IPv6 Mailing List
Subject: Re: Need for an overview [was ND Option for NMS Discovery-//FW: New Version Notification for draft-liu-6man-nd-nms-discovery-00.txt]

On Wed, Oct 23, 2013 at 9:43 PM, Brian Haberman <[email-masked]<mailto:[email-masked]>> wrote:

I agree that we're about due to attempt to have this conversation again. Who knows, now that we have more operational and deployment experience than we did last time, the outcome might be different.

Rather than have an argument based on single use cases, what might be useful is to start with a document that lists the basic technical properties / semantics of the mechanisms themselves. For example:

RA option: sent by the router; requires no server; hard to relay / apply policy; easy to update at any time, even if the original router has crashed; scales with router CPU; shares fate with routing; supports merging multiple sources of information.

Stateless DHCPv6 option: sent by a server; requires a server; easy to relay / apply policy; scales with server CPU (which can be better or worse than router CPU depending on how many thousands/millions of clients you send to a single server); very hard to update from network side; doesn't share fate with routing; doesn't support merging multiple sources of information.

"We do it this way in IPv4" or "the market is asking for it" (which are mostly, though perhaps not entirely, the same argument) would explicitly not be a part of this document because they're not technical properties of the protocols.

The hope would be that we don't fundamentally disagree on the properties of the two provisioning protocols, only on which characteristics are more important in which deployment scenarios. If that's true, and we were able to agree on this document describing the properties, then we might later be able to move towards deciding what kinds of options go into which protocol.