Minutes of Remote Boot BOF
IETF 44 (Minneapolis, MN)
Thursday, March 18, 1999

Minutes reported by Mike Henry and Mike Carney.

Agenda:

1. Introduction and agenda bashing       Henry
2. Intel's Agenda                        Henry
3. Proposed Goals of WG                  Henry
4. Overview of PXE Protocol              Henry
5. Use of SLP for bootserver discovery   Guttman
6. Next Steps - Areas Needing Work       All


2. Intel's Agenda

  o Establish portions of the PXE 2.0 specification as RFC standards
    (http://developer.intel.com/ial/wfm/wfmspecs.htm)
     * remote boot protocol
     * remote boot mtftp for bootstrap download
     * IANA registration for
        - Booting Client types (Instruction Set Architecture)
        - Bootserver types

  o Migrate proprietary methods within PXE to IP standards as the
    standards become available

  o Provide path for remote boot support in Ipv6


3. Proposed Goals of WG

  Define a standard protocol between the remote boot client and the
  responding server(s).

  The Working Group objective is to produce a protocol that insures
  remote boot clients, of arbitrary platform and instruction set
  architecture, will be able to choose an appropriate boot program
  from an arbitrary variety of boot servers, without the necessity
  of site-specific pre-configuration of the client.


4. Overview of PXE Protocol

  Mike Henry gave an overview of the PXE remote boot protocol as defined
  in the following two drafts:

  Remote Boot  (draft-viswanathan-remote_boot-protocol-00.txt)
  MTFTP        (draft-viswanathan-remote_boot-mtftp-00.txt)

  [The slides for this presentation have been submitted with these
   minutes.]

  Discussion followed: ("C." - comment, "Q." - Question, "A." - Answer)

  C. Security: something we need to address if we're a working group
(Narten)

  C. The NBP (Network Bootstrap Program) credential transaction is not
     documented in the draft.

  C. We need to discuss the deficiencies of the current possibilities
    (methods) (Narten)


  Q. TFTP      issue raised - some companies will not use tftp (security
concern??)
     So, Appropriate for remote boot use??
  A. TFTP is current method for standard DHCP based boot roms.  This is not
     new.

  Q. Concern about key distribution?
  A. Only a public key is required for the platform; a private key is not
     required.  Further, the key is owned by the local IT organization.

  Q. MAC address is writable; are you aligned with IEEE802 body on this
issue?
  A. No. Do we need to be? Not qualified to comment on viability of
     dynamically writing MAC to guarantee its uniqueness, however,  UUID is
     guaranteed to be unique.
  C. Suggestion that we send a message to IEEE 802 body to announce our
issue

  C. Concern about use of unique identifiers (UUID as platform ID). Keep
     that in mind

  Q. Are PXE strings ASCII?
  A. (Not sure, check draft.  [this was an internationalization
     motivated question]

  Q. Is the server supposed to echo back "PXEClient" in Opt 60,
     or the clients class "PXEClient:Arch:xxx:yyyy")?
  A. Just "PXEClient" today....
  Q. Can you return the entire string?
  A. Not clear, some DHCP servers do not appear to distinguish between
     instances of Option 60.

  Q. Can the client send more identifying info (like kind of SCSI card,
etc.)
  A. This is a Black hole - we decided to let the second level boot
     program figure out additional HW config information.

  Q. What does "Intel Order" mean?
  A. "little endian".


5. Use of SLP for bootserver discovery

  Eric Guttman gave a short talk on how SLP could be used by the booting
  to discover a suitable bootserver, even to the extent of accomplishing
  this without use of a DHCP server.  (This would be useful in a
"networking
  in the small" environment.)

  You could use SLP to locate boot image (bootserver) - e.g.
    - Platform =0
    - UNDI =3
    - - Credential = S2
    - - UUID --......

  Works w/o DHCP
  +-------------+
  | Boot Client |   )) -->  Attribute request
  +-------------+             servicetype = remboot
          ^                    attr = platform, authen. Methods
          |
          |       Attr Reply
          | (platform = x86, sparc)
          |                            +-------------+
          +----------------------------| Boot Server |
                                       +-------------+


  Replace dhcp w/ slp for discovery of bootservers [actually, replace
  proprietary PXE discovery protocol w/ slp]

  Q. Can you still encode policy / menu to clients with SLPv2?
  A. Yes - selection among attributes

  Must be able to interdict preboot or postboot for administration
  - SLPv2 can do this - Erik gave other example (Open Group)

  Q.  How to set/determine priority of Boot Servers?
  A.  Could have a priority attribute to communicate to the client which
      boot image from a group to select.


  A document describing minimal use of SLP as discovery method for
  Bootservers is needed to clarify how SLP would work and the extent
  of change that would be necessary from current method.  Eric
  volunteered to write this up.

6. Next Steps - Areas Needing Work

  Areas Needing Work
  1. Security must be addressed in updated drafts
  2. The problem to be solved by a Remote Boot working group must be
     defined by a requirements document that outlines remote boot
     requirements and what requirements are currently not addressed.
     In other words, what is inadequate about what is currently defined?
  3. Consideration of Mobile Clients

  Next Steps
  1. Write Requirements Document      (Mike Henry, Mike Carney,
                                       Marc Blanchet)
  2. Investigate current protocols.
  3. Decide what is warranted (choose):
      a.  a new standard
      b.  a BCP RFC document use of best use of current standards
      c.  no action; current standards are adequate
  4. Need a MIB
  5. Write SLP discovery doc.         (Eric Guttman)

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.