home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ospf / ospf-minutes-97apr.txt < prev   
Encoding:
Text File  |  1997-05-29  |  8.9 KB  |  227 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4.     A joint session of the OSPF    and MOSPF Working Groups met on    Wednesday,
  5.     April 9th from 1300-1515 at    the Memphis IETF. Minutes of the meeting
  6.     follow:
  7.  
  8.     (1)    John Moy gave a    summary    of the current status of the following
  9.     documents:
  10.  
  11.     o   The    OSPFv2 specification, <draft-ietf-ospf-version2-10.txt>, is
  12.         in IESG last call. It is expected to be published as an RFC, at
  13.         Full Standard status, replacing RFC    1583.
  14.  
  15.     o   The    MOSPF specification, RFC 1584, needs to    be updated. There
  16.         are    small problems in inter-area multicasting in the presence of
  17.         virtual links, and when adding stub    links to the forwarding
  18.         cache entries. Also, the document should mention that when
  19.         IGMPv2 is being used, IGMP elects the querier instead of using
  20.         the    OSPF DR. Finally, John wants to    add a feature where ranges
  21.         of multicast addresses can be configured in    area border routers
  22.         as being "area local". After these changes are made, the
  23.         document can probably be submitted for Draft Standard status, as
  24.         there are now a number of implementations.
  25.  
  26.     o   The    OSPF for IPv6 specification, <draft-ietf-ospf-ospfv6-
  27.         04.txt>, was recently updated: a) the IPv6 pseudo-header was
  28.         added to the OSPF packet checksum, to protect against corruption
  29.         of the IPv6    header,    b) MTU was added to the    Database Description
  30.         packet, porting the    MTU mismatch fix from OSPFv2, and c) the set
  31.         of LSAs that cannot    be flooded through stubs areas was
  32.         clarified, allowing    certain    AS-scoped LSAs on a case-by-case
  33.         basis. The only other pending changes involve the IPv6
  34.         encapsulation: the setting of the priority field and possibly
  35.         the    setting    of the TTL. The    specification is still awaiting
  36.         implementation experience before it    will be    published as an    RFC.
  37.  
  38.     (2)    Dave Jacobson from IBM made the    following patent disclosure:  "IBM
  39.     believes that it has patents(4644532, 4827411) which may relate    to
  40.     OSPF and in accordance with the    intellectual property rights
  41.     procedures of the IETF standards process, IBM is willing to offer
  42.     non-exclusive licenses under reasonable    and non-discriminatory
  43.     terms and conditions.  Any party wishing to request a license should
  44.     write to:  IBM Director    of Licensing, IBM Corporation, 500 Columbus
  45.     Avenue,    Thornwood, New York 10594". No further information was made
  46.     available.
  47.  
  48.     (3)    Rob Coltun presented the latest    changes    to his Opaque-LSAs draft,
  49.     which will be published    as an Internet Draft after the meeting.    Two
  50.     changes    have been made:    a) separate LS types have been assigned    to
  51.     Opaque-LSAs with link-local, area, and AS flooding scope (LS types
  52.  
  53.  
  54.  
  55.                     [Page 1]
  56.  
  57.  
  58.  
  59.  
  60.  
  61.     9, 10 and 11, respectively), and b) the    flooding rules were changed
  62.     so that    Opaque-LSAs with AS flooding scope will    not be flooded
  63.     into/throughout    stub areas.
  64.  
  65.     It was decided to give administration of the Opaque type field to
  66.     IANA, since we already have a conflict (between    Rob's ARA proposal
  67.     and the    MOSPF pruning proposal;    see below). Sandy Murphy questioned
  68.     why the    stub area rules    were different for Opaque-LSAs vs. the LSAs
  69.     in OSPF    for IPv6. The reason is    that the "flood    even if
  70.     unrecognized" bit and the increased size of the    Options    field in
  71.     IPv6 allows us finer control than the all or nothing decision (where
  72.     nothing    seems most appropriate for stub    areas) possible    with
  73.     Opaque-LSAs.
  74.  
  75.     Since we are now out of    Options    bits in    OSPFv2,    we expect all new
  76.     OSPFv2 options to be implemented using Opaque-LSAs. For    this reason,
  77.     we will    try to get the Opaque-LSA document published as    a Proposed
  78.     Standard as soon as possible.
  79.  
  80.     (4)    Rob Coltun then    presented an application of Opaque-LSAs    that he    has
  81.     developed together with    Juha Heinanen (Telecom Finland)    and Yiqun
  82.     Cai (Nortel). Called the address resolution advertisement or ARA, it
  83.     uses Opaque-LSAs to advertise mappings between IP addresses (or    OSPF
  84.     Router IDs) and    ATM NSAPs. This    allows the establishment of control
  85.     driven shortcuts across    legacy ATM clouds. This    work was also
  86.     presented to the ION working group.
  87.  
  88.     (5)    Pat Murphy (USGS) talked about the work    he has been doing to update
  89.     the NSSA area specification (RFC 1587).    He has added two features:
  90.     the ability to omit summary advertisements from    NSSA areas, and    the
  91.     ability    to configure which area    border routers do the translation
  92.     from type-7 LSAs to type-5 LSAs. The first can keep the    NSSA
  93.     database size even smaller (although can't be used when    the NSSA
  94.     area employs "private" defaults), while    the second can optimize
  95.     routing    when aggregation is taking place (and so forwarding
  96.     addresses cannot be used). There was some discussion of    whether    it
  97.     would be better    to have    all border routers perform the translation,
  98.     analogous to OSPF's treatment of summary-LSAs. Pat also    updated    the
  99.     type-7 route calculation to make it compatible with the    updated
  100.     external route calculation in the latest OSPFv2    draft.
  101.  
  102.     (6)    Sanjay Kamat (IBM) presented a proposal    for QoS    path management    with
  103.     RSVP <draft-guerin-qospath-mgmt-rsvp-00.txt>. The goal of this work
  104.     is to have RSVP    set up the paths selected by QoS routing algorithms,
  105.     and provide support for    route pinning while detecting loops in path
  106.     setup. Other goals were    to change RSVP as little as possible, keep
  107.     its soft state model, and work with any    QoS routing protocol. The
  108.     interface between RSVP and routing is modified,    with RSVP passing
  109.  
  110.  
  111.  
  112.                     [Page 2]
  113.  
  114.  
  115.  
  116.  
  117.  
  118.     the Tspec as well as source and    destination addresses. The RSVP    PATH
  119.     messages are then forwarded along the path selected by the QoS
  120.     routing    algorithm. This    work was also presented    to the QoS routing
  121.     WG.
  122.  
  123.     (7)    Tony Przygienda    (FORE) gave an update on "QoS Routing Mechanisms and
  124.     OSPF Extensions",  <draft-guerin-qos-routing-ospf-01.txt>, joint
  125.     work done by himself and Guerin, Kamat,    Orda, and Williams (IBM).
  126.     Tony restricted    his talk to the    changes    since last meeting. Instead
  127.     of changing the    format of router-LSAs, they now    encode their metrics
  128.     using OSPF's TOS encodings. To enhance backward    capability, TOS
  129.     values were chosen so that OSPF    implementations    which only look    at 4
  130.     TOS bits would interpret their bandwidth metric    (TOS 0x10100) as
  131.     "maximize throughput", and their delay metric (TOS 0x11000) as
  132.     "minimize delay". Metric values    are encoded using exponential
  133.     encoding, with a 7-bit exponent    and a 5-bit mantissa, to fit in
  134.     OSPF's 16-bits.    They are also using a new Option bit, the Q-bit, to
  135.     indicate that a    router is running the QoS enhancements.
  136.  
  137.     Ongoing    work includes OSPF area    support    (whether to support
  138.     heterogenous areas, and    how to aggregate QoS metrics), and
  139.     extensions to additional metrics (such as jitter).
  140.  
  141.     (8)    John Moy presented work    he has been doing to add prune support to
  142.     MOSPF. This has    two independent    parts. The first allows    unnecessary
  143.     wild-card multicast receivers to be pruned from    multicast delivery
  144.     trees during inter-area    and inter-AS multicasting. Prune packets (a
  145.     new OSPF packet    type) are sent upstream    (toward    the source) when
  146.     forwarding cache entries are built with    no downstream interfaces.
  147.     Prune packets contain a    list of    the wild-card receivers    that need
  148.     not be included    in the delivery    tree; this allows prune    maintenance
  149.     to be delegated    to the wild-card multicast receivers themselves.
  150.  
  151.     Jeffrey    Zhang thought prune information    should be advertised in
  152.     LSAs; John's stated reason for using packets was that flooding the
  153.     prune information forces routers to hold more information than they
  154.     need. Tom Maufer (3com)    said that prunes and prune deletes should be
  155.     made reliable, rather than just    relying    on timeouts. Hal Sandick
  156.     (IBM) asked whether interaction    with shared tree multicast routing
  157.     protocols had been considered; John admitted that he hadn't spent
  158.     much time on that issue.
  159.  
  160.     The second part    of the work allows IGMPv3's source-specific group
  161.     membership information to be advertised    within MOSPF. Two new LSAs,
  162.     the source-join-LSA and    source-leave-LSA, are used. Both are built
  163.     on top of the area-scoped Opaque-LSA. Both have    properties similar
  164.     to the MOSPF group-membership-LSA: they    are specific to    a single
  165.     area, and are summarized at area boundaries going up the hierarchy
  166.  
  167.  
  168.  
  169.                     [Page 3]
  170.  
  171.  
  172.  
  173.  
  174.  
  175.     (but not down).
  176.  
  177.     This work will be published as an Internet Draft after the meeting.
  178.  
  179.     (9)    The meeting ended with Path Murphy describing his large    inter-agency
  180.     OSPF network, and the circumstances in which he    would like to prefer
  181.     inter-area routes over intra-area routes. Pat proposed protocol
  182.     changes    to accomplish his goal.    Some discussion    ensued as to whether
  183.     it was better to make protocol changes,    or to just configure
  184.     multiple subnets per link, which could achieve the same    thing.
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.                     [Page 4]
  227.