The IP Over NBMA (ION) Archive

["Eric W. Gray" <gray@cabletron.com>]

Folks,

        I tried to re-sequence this dialogue (multi-logue?) in order to
provide context.  Believe it or not, it's actually less clutter that way.
In any case, I appologize in advance to anyone who might feel slighted by
some apparent change in the order of original delivery.  There were several
parallel threads going on.

        For the record, participants in the discussion were:

            Grenville Armitage <gja@bellcore.com>
            Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
            Keith McCloghrie <kzm@cisco.com>

Any comments I have are separated from the rest of the discussion by lines
with stars in them...

Grenville:
    Jim (and world),

    I've had a number of private emails in the last few months from
    implementors wondering about the common LLC/SNAP codepoint that
    MARS and NHRP use, so I figure we need some minor clarifying
    words in nhrp-09. I've suggested substitute 'plug in' text.

Masataka:
    Urrr, but, so far, the only counter argument to my inscalability
    draft is that NHRP may still be useful over X.25 or something like
    that (though some people stated that some improvement could make
    NHRP scale, it is not counted as a valid argument).

    I have seen no one who expressed interest in inscalable NHRP
    over ATM.

  ***************************************************************************
    To say that no-one has "expressed interest" in NHRP is blatantly
    untrue but in this sentence you assert the qualifier "inscalable".
    Did you do this in order to make the untruth less blatant or to
    "prove" your point by assertion (I think it therefore it is true)?
  ***************************************************************************

Keith:
    Continually repeating inflamatory statements does not make them any
    more true than the first time you said them.

Masataka:
    Of course.

    I just want to confirm that there is no valid counter argument.

    So, in the NHRP draft, anything related to ATM is irrelevant and
    should be removed or replaced by something X.25 specific.

Keith:
    See my comment above.

  ***************************************************************************
    Keith is correct here - Ohta-san is attempting to prove his point
    by repeatedly asserting his conclusion.  "Eggs are <insert color>
    therefore NHRP is a waste of time."
  ***************************************************************************

Masataka:
    After that, the draft may become an experimental RFC unrelated to
    ION WG.

    Or, are there anyone who can argue unicast only ATM worth having?

Keith:

    If the question is whether applying NHRP to ATM only for p2p VCCs (and
    not applying it to p2mp VCCs) is worth having, then the answer is yes.
    In particular, one use of it is in MPOA, and the agreement on "MPOA
    Phase 1" at last week's ATM Forum meeting was very well received.

Masataka:
    Your reasoning that we need some specification because another
    specification needs it, is rather circular.

Keith:
    TCP needs the functionaliity of the IP spec, but that is not circular.

Masataka:
    Do you want to say that we need IP only because TCP needs IP?

Keith:
    No, I was just explaining by analogy that my reasoning was not circular.

  ***************************************************************************
    The specification is needed and NOT because it refers to itself.
    Earlier, Masataka states that NHRP may be useful for X.25.  Here Keith
    suggest that it is useful for MPOA - which is clearly not X.25.
    Would anyone suggest that NHRP should be separately specified in both
    places?
  ***************************************************************************

Masataka (continuing from before):
    If you want to continue effort on NHRP in ATM forum, that's fine
    for us IETF.

    But, it does not mean that unicast-only MPOA is worth having.

Keith (1):
    It is *not* unicast-only MPOA.  MPOA *does* support multicast; it just
    doesn't use NHRP-derived shortcuts for multicast.

  ***************************************************************************
    A minor clarification - the reduced version of MPOA suggested as MPOA
    phase 1 no longer includes definition of those "functional groups" that
    would provide MARS/MCS support.  This simply means that support of
    multicast services is not within the scope of phase 1 MPOA - not that
    MPOA does not support multicast.
  ***************************************************************************

Masataka (continuing from before):
    Then, if your logic is that unicast-only MPOA is worth having
    because it is the first step toward multicast capable MPOA,
    the technical fact is that you can't use NHRP.

Keith (2):
    1. On the contrary, my logic is that in unicast-and-multicast-MPOA it
    is worth using NHRP shortcuts for unicast even if it can't be used for
    multicast.

    2. Note that three years ago, the IETF specifically decided that:
    unicast-only 1577 was worth having because it was the first step toward
    multicast capable IP-over-ATM.

Masataka (IRT "Keith (1)" above):
    I'm confused.

    Doesn't it mean that MPOA does not need NHRP?

Keith:
    No, as my previous message (see above) said, MPOA uses NHRP for p2p
    shortcuts.

Masataka (continuing IRT "Keith (1)" above):
    Or, is it that multicast MPOA is somehow crippled and does not worth
    having?

Keith:
    No, just because MPOA's multicast traffic does not take shortcuts
    around routers, it doesn't mean it's crippled.  (Otherwise, multicast
    with CSRs would also be crippled, because multicast traffic does not
    take shortcuts around CSR routers).

  ***************************************************************************
    In a way, MPOA offers the best of both worlds because edge devices
    do not need to pay attention to whether or not traffic is unicast
    FOR THE PURPOSE OF DETECTING FLOW. What this means is that - where
    a portion of an ATM cloud provides the transport for a trunk/branch
    of a multicast tree (the "flow" of all packets is from one edge device
    to another), an edge device MAY establish a shortcut to support it.
    Note that, in this scenario, the ATM cloud is "not large" from the
    perspective of THIS multicast flow and Masataka's scaling issue does
    not exist.  For multicast support of multiple ATM-attached hosts
    within a single LIS (LAG/IASG), MPOA takes a side-line position and
    leaves the solution to MARS.  Note that, once again, in this scenario
    multicast scale is manageable.
  ***************************************************************************

Masataka:
    I see.

    It is perfectly OK to not to shortcut for multicast,
    as long as the topology is not so logical.

  ***************************************************************************
    "Logical" in networking is largely a perspective issue - you show
    me a network that is logical from one perspective and I'm sure that
    someone can provide you with a perspective from which it is "not so
    logical."
  ***************************************************************************

    The problem, then, is that we don't need unicast shortcut.

    That is, NHRP is not useful for unicast and not worth having.

    BTW, if MPOA multicast does not support ATM QoS, it's crippled.
    If it does, they need CSRs and network layer specific resource
    reservation protocols (like RSVP/ST2 for IP).

    Is MPOA multicast crippled to be best effort only?

Masataka (continuing):
    Are there any published document on what is "MPOA Phase 1" and
    latter phases?

Keith:
    Not yet.

Masataka (IRT "Keith (2)" above):
    Of course.

    RFC 1577 was a step toward multicast capable IP-over-ATM.

    But, NHRP is proven to be not a step toward multicast capable
    IP-over-ATM.

  ***************************************************************************
    So far, you've managed to convince a lot of people that NHRP is
    not a solution for scalable multicast over large clouds over ATM.
    That is a far cry from the proof you assert here.  Would you care
    to elaborate on how you get from one to the other?
  ***************************************************************************

    That's the difference.

Keith:
    Whether this is true is irrelevant.  The bottom line is that NHRP is
    useful for unicast, irrespective of its scaling properties for
    multicast, and therefore should be progressed as a Proposed Standard.

Masataka:
    The bottom line is that NHRP is not useful for unicast over
    multicast-capable network including ATM, and therefore
    should be dismissed.

  ***************************************************************************
    What do you fear here, Masataka?  If you are right - and NHRP SHOULD
    be dismissed - then get out of the way and, as soon as it is proposed,
    it WILL be dismissed.
  ***************************************************************************

Keith:
    Your statements make no sense.  I give up trying to reason with you.

Masataka:
    Thank you very much for your information that MPOA must use CSRs.

  ***************************************************************************
    The fact that someone tires of attempting to reason with you does not
    mean that they concede your point. In fact, it may mean that they have
    joined the throngs of people who have instituted a "noise filter" in
    their mail reader (I wonder if having a filter named after you means you
    are famous?).
  ***************************************************************************

Masataka (continuing):
    BTW, can someone counter argue the unicast inscalability of NHRP
    that Grenville and I pointed out?

Grenville:
    Just exactly where did 'we' point this out and challenge the
    group to respond? Our personal conclusions wrt unicast NHRP
    are different in subtle but important ways. Don't mix them.

Masataka:
    As I stated earlier, the current spec says NHRP hosts connect VC
    directly to the egress router with no intermediate routers in
    the cloud, which causes VC implosion and makes unicast NHRP not
    scale.

  ***************************************************************************
    The "implosion" occurs only if a shortcut is created for every flow
    detected and a flow is considered to have been detected on receiving
    a VERY small number (read "one") packet to a given L3 destination.
    This will almost certainly not be the case.  Also, I believe you are
    incorrect in your assertion that shortcuts never use intermediate
    routers.  There are clear cases where an NHR query is required to be
    terminated at an interior router (which may respond either with an
    error or with its own NBMA address information).  In addition, there
    are extensions to the protocol that allow an ingress router or NHC to
    recover when the NBMA address it has received cannot be used (e.g. -
    out of connection resources).  "Unicast inscalability" does not seem
    to me to be an issue.
  ***************************************************************************

Grenville (continuing):
    _________________________________________________________________________

    Section 5, 4th paragraph:

       NHRP packets are encapsulated using the native formats used on the
       particular NBMA network over which NHRP is carried.  For example,
       SMDS networks always use LLC/SNAP encapsulation at the NBMA layer,
       and an NHRP packet is preceded by the following LLC/SNAP
       encapsulation:

       [0xAA-AA-03] [0x00-00-5E] [0x00-03]

       The first three octets are LLC, indicating that SNAP follows.  The
       SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
       identifies NHRP (see [4]).

    replace with:

       NHRP packets are actually members of a wider class of address mapping
       and management protocols being developed by the IETF. A specific

  ***************************************************************************
    I wonder if it would not be better to state this as "... protocols that
    may be developed under the cognizance of the IETF."  I'm a little leary
    of a direct reference to "protocols being developed by the IETF."  It is
    too limiting.
  ***************************************************************************

       encapsulation, based on the native formats used on the particular NBMA
       network over which NHRP is carried, indicates the generic IETF mapping
       and management protocol. For example, SMDS networks always use
       LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet is
       preceded by the following LLC/SNAP encapsulation:

       [0xAA-AA-03] [0x00-00-5E] [0x00-03]

       The first three octets are LLC, indicating that SNAP follows.  The
       SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
       identifies the mapping and management protocol. A field in the
       Fixed Header following the encapsulation indicates that it is NHRP.

  ***************************************************************************
    Because of the way you have tied SMDS network use of LLC/SNAP and NHRP
    (you used "and" to make it a single sentence - spell it "thought"), I
    can't tell if you're saying that this example only applies to NHRP over
    SMDS.  I can't really suggest better wording because I really don't
    know what you are trying to say (I also realize that the original words
    are not yours).
  ***************************************************************************

    ________________________________________________________________________

    Section 5.1:

       ar$op.version
         This field is set to 0x01 for NHRP version 1.

    replace with (codepoint space modified from draft-ietf-ipatm-ipmc-12):

       ar$op.version
          This field indicates what version of generic address mapping
          and management protocol is represented by this message.

             0               MARS protocol [11].
             1               NHRP as defined in this document.
             0x02 - 0xEF     Reserved for future use by the IETF.
             0xF0 - 0xFE     Allocated for use by the ATM Forum.
             0xFF            Experimental/Local use.
    _________________________________________________________________________

    Section 5.1:

       ar$op.type
         This is the NHRP packet type: NHRP Resolution Request(1), NHRP
         Resolution Reply(2), NHRP Registration Request(3), NHRP
         Registration Reply(4), NHRP Purge Request(5), NHRP Purge Reply(6),
         or NHRP Error Indication(7).  Use of NHRP packet Types in the range
         128 to 255 are reserved for research or use in other protocol
         development and will be administered by IANA.

    replace with:

       ar$op.type
         When ar$op.version == 1, this is the NHRP packet type:
         NHRP Resolution Request(1), NHRP Resolution Reply(2),
         NHRP Registration Request(3), NHRP Registration Reply(4),
         NHRP Purge Request(5), NHRP Purge Reply(6), or NHRP Error
         Indication(7).  Use of NHRP packet Types in the range
         128 to 255 are reserved for research or use in other protocol
         development and will be administered by IANA.
    _________________________________________________________________________

    Section 5.3:

    (this is just a suggestion, which I also used in ipmc-12, because
    it allows use of TLVs by non-IETF organisations or researchers without
    having them bother ION or IANA.)

       Type
         The extension type code (see below).  The extension type is not
         qualified by the Compulsory bit, but is orthogonal to it.

    replace with:

       Type
         The extension type code (see below).  The extension type is not
         qualified by the Compulsory bit, but is orthogonal to it.
         The TLV type space is subdivided to encourage use outside
         the IETF:

          0                       Null TLV.
          0x0001 - 0x0FFF         Reserved for the IETF.
          0x1000 - 0x11FF         Allocated to the ATM Forum.
          0x1200 - 0x37FF         Reserved for the IETF.
          0x3800 - 0x3FFF         Experimental use.
    _________________________________________________________________________
    References:

    Add (to support the changes Section 5.1) :

      [11]  G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM
       Networks.", Bellcore, INTERNET DRAFT, draft-ietf-ipatm-ipmc-12.txt,
       February 1996.

    (this will have an RFC number in the next few weeks, so we can edit
    it then.)
    _________________________________________________________________________


Eric Gray
mailto:eric.gray@nh.ultranet.com / gray@ctron.com
http://www.nh.ultranet.com/~egret