Subject: [OPSAWG] more commentary needed on draft-ietf-opsawg-automated-network-configuration-01.txt

From: Kent Watsen <[email-masked]>
Date: Mon, 11 Jul 2011 17:31:52 -0700

First time poster here.

This draft was brought to my attention since it referenced my "Reverse SSH" draft. 
FWIW, I made some notes while reading it...

Thanks,
Kent

Section 1:

  - Why the emphasis on SP networks?  The same problems exist in large
    enterprise networks.  For instance, retail outlet stores (7-11, Gap, etc)
    also have the need to roll out many devices, which connect to a 3rd-party
    network provider (i.e. the inter-domain scenario) 
  - I disagree with the statement "A certain amount of the information needed
    to operate them must be pre-configured by the vendor or service provider
    before the devices are physically deployed".   At least, we (Juniper)
    have low-touch deployment solutions that do not require any pre-staging.
    One based on the device reading a USB pen-drive, the other based on using
    a DHCP server...
  - nit: replace:
      "but SNMP has not historically seen only limited use for..."
    with:
      "but SNMP has historically seen only limited use for..."

Section 2:

  - the Inter and Intra definitions are helpful.  We've identified the need
    to support the same two scenarios at Juniper.
  - the last paragraph states that middleboxes may impose restrictions on 
    which peer can initiate communication.  While this is a true statement,
    it may be more important to note the device-initiated connections may
    be desirable for a number of reasons.  Six reasons are identified in 
    draft-kwatsen-reverse-ssh-00's "Introduction" section.

Section 3:

  - Does the "Pre-configuration" step require the physical device?  Our pre-
    configuration step is primarily in the NMS - to model the device
    so it know what to do when the real device shows up.  From which we can 
    save out the file to a USB pen-drive or update a DHCP server...
  - Can "Initial configuration" be extended to include updating everything
    on the device?  - firmware, licenses, certificates, configuration, etc.

Section 5.2:

   - I found this section informative, thanks
   - there is another means for the device to acquire its IP address and
     basic routing information, which is for it to read said data off of
     a portable drive (i.e. a USB pen drive) plugged into the device while
     it powers on.

Section 5.3:

   - a 5th alternative is, again, for the device to read said data from a
     portable drive plugged into it while it powers on
   - Using the portable-drive to supplement the additional configuration
     works well for Inter-domain scenarios

Section 5.4:

   - using an invariant identity built-in may not always be desirable.
     For instance, a shared-id may be preferred, to leverage a shared
     template.  Similarly, using a CLIE code allows the association to
     float between physical devices (doesn't matter which the user grabs)
   - reading the invariant from a bar-code affixed to the package implies
     that the device is staged prior to being shipped to its destination.
     Since we don't do that, I don't think the draft can assume this is
     the case and consider the problem solved...
   - the DUID is a good idea, but it's surprising that "serial-number"
     wasn't listed.  Of course, if it is mentioned, please be sure to
     note that it is NOT RECOMMENDED to pass serial-numbers in the clear
     for security reasons, as they sometimes encode model-numbers,
     manufacturing dates, etc.
   - listing out transports is OK, but would it better to list out 
     configuration protocols (i.e. SNMP, TL1, NETCONF, etc.) and then
     consider how they can be secured?  Maybe a matrix would be best.
     Of course, coming from the NetConf WG, which IETF chartered to
     better the others, my thoughts are, is there really any point to
     discussing any protocol other than NETCONF  ;)
   - FWIW, in an Intra-domain scenario, the network may be already be 
     secured (i.e. private) thus reducing the need for transport-level
     security.  That said, I'm sure vendors would prefer to just implementing
     support for one transport that can satisfy all use-cases
   - regarding shared-secrets, note that if using a USB pen-drive with
     a shared id (not invariant) then the solution does scales nicely, not
     linearly as written in the draft
   - I didn't follow the need to the device to authenticate itself (CAPWAP?),
     But agree the certificates are a good thing.
   - While a the SP's CA is ideal, a vendor's CA is OK.  That is, the NMS
     knowing it's to a vendor's means that it's NOT connected to a man in
     the middle.  Also, in cases when the device is drop-shipped to the
     destination from the vendor, there isn't much choice...

Section 6:

   - FWIW, I'm of the opinion that the software and configuration should be 
     pushed to a device (not pulled from it).  Assuming an NMS is in play,
     it can do a better job orchestrating these updates
   - s/asychronous even notification/asynchronous event notification/ (2 typos)
   - I'm surprised that the "second class of protocols" doesn't list
     TL1 or MTOSI or, even the ubiquitous CLI

Section 8:

    - in the missing specifications section, do you want to add a spec to 
      define MAC and/or serial-number fields in x.509 subject alt name?

Thanks,
Kent

---

From: "George, Wesley" <[email-masked]>
Date: Wed, 13 Jul 2011 12:44:11 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Monday, July 11, 2011 8:32 PM
To: [email-masked]
Subject: [OPSAWG] more commentary needed on draft-ietf-opsawg-automated-network-configuration-01.txt

Section 6:

I'm not sure I agree with this. Every network will be a bit different, but there are cases where this requires a multi-step (and IMHO unwieldy) process to make it work, especially in scenario 2 where there is another network involved. First you have to pre-provision (build) the device in the NMS, then you have to have some means to determine the IP address that the device is using once it comes online so that you can set the NMS at talking to it. It will not always be practical to wait for an NMS discovery run to find new devices and put them on the queue to be provisioned, or even to expect NMS discovery to be the appropriate method to find new devices. I'm skeptical that periodically wandering through subnets to find new kit is practical on a single /64, let alone an entire network-sized IPv6 block.
At a minimum, the device has to be able to call home to identify itself and ask for the config, even if that (optionally) triggers the NMS to make a connection and push the config on its timeline instead.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.