Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH (fwd)

From: Shankar Vemulapalli <[email-masked]>
Date: Wed, 13 Feb 2002 09:34:13 -0800 (PST)

Sorry for any duplicate e-mail if you receive any.
Got an e-mail from isis-wg-admin saying it has too many recipients -
Sending it again if you haven't received one.

Thanks,

/Shankar

---------- Forwarded message ----------
Date: Wed, 13 Feb 2002 09:19:55 -0800 (PST)
From: Shankar Vemulapalli <[email-masked]>
To: Micah Bartell <[email-masked]>
Cc: Philip Christian <[email-masked]>,
     'Jeff Learman' <[email-masked]>, Tony Przygienda <[email-masked]>,
     Les Ginsberg <[email-masked]>, 'Tony Li' <[email-masked]>,
     Ken Larmer <[email-masked]>,
     "Chan, Chung Ming" <[email-masked]>, [email-masked],
     'Alex Zinin' <[email-masked]>
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

Hi Michah -

It is looking good with a good start.

Couple of points/notes:

In the "Introduction" section, I would probably add some more [general] description
that in existing production neteworks the number of ES are very less and that
this is even more true on the p2p interfaces [in those lines].

Also, it would be good to add saying that the vendors can have knob to turn
on or off this ISH packets on the p2p interfaces.

Any adv or dis-adv on the routers CPU or any other one by just sending IIH vs
IIH + ISH - [a thought + whether to address this issue]

Thanks,

/Shankar

At 10:35am 02/13/02 -0600, Micah Bartell wrote:
> Alright, I have no idea who is working on a draft at this point.  Feel free
> to hack off of this one, which was just a bit of scribbling late last night.
>
> /mpb
>
>
>                IS-IS Adjacency Establishment in IP Only Environments
>                       <draft-ietf-isis-ipadj-00.txt>
>
>
> 1. Status of this Document
>
>     This document is an Internet-Draft and is in full conformance with all
>     provisions of Section 10 of RFC2026.
>
>     Internet-Drafts are working documents of the Internet Engineering Task
>     Force (IETF), its areas, and its working groups. Note that other groups
>     may also distribute working documents as Internet-Drafts.
>
>     Internet-Drafts are draft documents valid for a maximum of six months
>     and may be updated, replaced, or obsolete by other documents at any
>     time. It is inappropriate to use Internet-Drafts as reference material
>     or to cite them other than as "work in progress."
>
>     The list of current Internet-Drafts can be accessed at
>     http://www.ietf.org/ietf/1id-abstracts.txt
>
>     The list of Internet-Draft Shadow Directories can be accessed at
>     http://www.ietf.org/shadow.html.
>
> 2. Abstract
>
>     This document describes a modification to the IS-IS protocol in IP Only
>     environments for adjacency establishment over Point to Point circuits.
>     The IS-IS protocol is specified in [2], with extensions for supporting
>     IPv4 specified in [1].
>
>     This draft describes a modification to the IS-IS protocol, which will
>     allow an IS-IS adjacency to be established over Point to Point circuits
>     without the use of an Intermediate System Hello PDU (ISH).
>
> 3. Introduction
>
>     The IS-IS protocol as defined in [1] was intended for use with the
>     Connectionless Network Service (CLNS).  An Intermediate System would
>     announce it's existance through the issuance of an ISH PDU, to allow
>     End Systems (ES) to form an ES-IS adjacency providing connectivity.
>     Typically an ES would exist on an broadcast subnetwork.  It is possible
>     for an ES to connect to an IS via a Point to Point circuit, creating
>     the requirement for an ISH PDU to be first issued over a Point to
>     Point circuit.  An IS on the Point to Point circuit would issue an
>     Intermediate System to Intermediate System Hello PDU (IIH) in response
>     to the ISH PDU.
>
>     In an IP Only environment, there is no need to issue an ISH PDU over a
>     Point to Point subnetwork because there are no End Systems with which to
>     form an ES-IS adjacency.  [2] requires that an ISH be received in order
>     to issue an IIH PDU.
>
> 4. Best Common Practice
>
>     An IP Only implemenation has no need to issue an ISH PDU as described in
>     section 8.2.4 of [2].  An IP Only implementation MAY issue an IIH PDU
>     when a Point to Point circuit transitions into an "Up" state to
>     initiate the formation of an IS-IS adjacency.  The IIH PDU SHOULD still
>     be issued in conformance with section 8.2.4 of [2] with the exception
>     of the requirement for reception of an ISH PDU.
>
>     An implementation that supports the forwarding of CLNS PDU's MUST act in
>     full accordance with section 8.2.4 of [2] when CLNS functionality is
>     enabled, including the initial issuance of an ISH PDU.
>
> 5. Security Considerations
>
>     This document raises no new security issues for IS-IS.
>
> 6. References
>
>     [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual
>     Environments" RFC 1195, December 1990
>
>     [2] ISO, "Intermediate System to Intermediate System Intra-
>     Domain Routeing Exchange Protocol for use in Conjunction with the
>     Protocol for Providing the Connectionless-mode Network Service (ISO
>     8473)", ISO/IEC 10589:1992
>
> At 15:51 02/13/2002 +0000, Philip Christian wrote:
> >Yes of course. The conclusion is then:-
> >
> >1. If you don't send ISHs, then it makes sense to send IIH instead as soon
> >as a circuit is enabled, as per 10589:1992.
> >
> >2. If you don't process incoming ISHs, and, if the other end sends only
> >ISH upon circuit enable, then you might have to wait one iSISHelloTimer
> >interval before you see him.
> >
> >3. If you follow 10589:1992+TC1 or 10589:2001 and only send ISH upon
> >circuit enable, then the you might have to wait for one iSISHelloTimer
> >before he sees you, but, if you follow 10589:1992 and send IIH upon
> >circuit enable then the other end is guaranteed to see you straight away.
> >
> >These are simple facts that can be stated, along with the fact that there
> >are implementations out there which do not send ISHs.
> >
> >I guess that I can start typing the draft now.
> >
> >Philip
> >>-----Original Message-----
> >>From: Jeff Learman [mailto:[email-masked]]
> >>Sent: 13 February 2002 15:14
> >>To: Christian, Philip [HAL02:GI50:EXCH]
> >>Cc: Tony Przygienda; Micah Bartell; Les Ginsberg; 'Tony Li'; Ken Larmer;
> >>Shankar Vemulapalli; Chan, Chung Ming; [email-masked]; 'Alex Zinin'
> >>Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH
> >>
> >>At 07:43 AM 2/13/2002, Philip Christian wrote:
> >>
> >>>So I have been thinking a little about the wording of a document to
> >>>describe the situation/history with ISHs and to mandate that an
> >>>implementation must be able to cope with ISHs or lack of ISHs.
> >>>
> >>>I have hit a problem.
> >>>
> >>>I assume that there are implementations out there that simply totally
> >>>ignore incoming ISHs, and actually do nothing until they receive an
> >>>IIH.  Would this be considerred legal or illegal behaviour in the doc
> >>>that I am thinking of drafting?
> >>
> >>First of all, I think it would be best to create an informational
> >>RFC, alerting implementors to common practice.  That way, we avoid
> >>legal vs. illegal, and simply describe behavior that an implementation
> >>is recommended to be able to interoperate with.  In this way, we can
> >>point out different interpretations of the spec, which is helpful
> >>to implementors without creating a new spec and new contradictions.
> >>
> >>Whether an informational RFC should contain a number of items or
> >>whether there should be one per issue I leave to the others to hash
> >>out -- evidently it's been hashed out a bit already.  I can see
> >>pros and cons on both sides of that issue.
> >>
> >>>According to 10589 the action on receipt of an ISH is that a new
> >>>adjacency is created with adjacencyState "Initialising" and an IIH PDU
> >>>is sent. As the IIH would be sent anyway whenever ISISHelloTimer
> >>>expires, then there are maybe two consequences:-
> >>>
> >>>1. The adjacency going to "Initialising", which one could argue is a
> >>>non-event, as an adjacency that is "Initialising" cannot be used for
> >>>anything, and the state will be ignored when an IIH finally comes along anyway.
> >>
> >>I agree, and therefore don't think it's necessary to specify anything.
> >>We should focus on observable behavior, not internal models.  It's hard
> >>to write a good spec without an internal model, so I'm not criticizing
> >>10589 here.  But in this case, we don't need to exacerbate the problems
> >>caused by specifying an internal model, we can just talk about behavior.
> >>The hard work has already been done.
> >>
> >>>2. Does it mean that the adjacency might come up faster as it doesn't
> >>>have to wait for a ISISHelloTimer to timeout?
> >>
> >>I assume that implementations that don't send ISH PDUs also don't wait
> >>for a timer to expire, they just send the IIH when the circuit comes up,
> >>so the adjacency would come up right away in either case.  Note that
> >>10589:1992 says to send the IIH when the circuit is first enabled;
> >>only 10589:1992+TC1:1993 says to wait to receive an ISH.  Some
> >>implementations don't follow TC1, which clearly says when to send the
> >>ISH.  Prior to that, there's only the implication that you wait to send
> >>an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1).
> >>
> >>>The only other use for ISH seems to be if a router wants to act as an
> >>>OSI End-System for some reason.  I haven't quite figured out why/when/if
> >>>an OSI router needs to also have End-System functionality, unless it is
> >>>something to do with OSI redirects.  It would seem to me that if a
> >>>router needs to have ES functionality is could attach it to itself
> >>>rather than to its neighbour.  What am I missing here?  Why can't you
> >>>have an OSI router that is only an IS, and, if so why does it need to
> >>>worry about ISHs?
> >>
> >>The only real purpose of the ISH is in case the system at the other end
> >>supports CLNP but is not running IS-IS, such as when it's an ES.  Assuming
> >>the OSI router's NSAP matches its NET (except for NSEL), then its network
> >>service users are reachable without doing anything special.  Admittedly,
> >>according to rule changes in TC1:1993, the ISH also serves the purpose of
> >>starting the process to bring up the adjacency.  But this is unnecessary.
> >>The only information in the ISH that is pertinent is "I'm a router!"
> >>
> >>By the way, the ISH is neither necessary nor sufficient for handling
> >>network service users on the OSI router, which is very important but
> >>was ignored in a lot of the early OSI standards.  There are two cases:
> >>(a) all NSAPs for the network service user matches the NET (except for
> >>NSEL), and (b) there are NSAPs that don't match the NET.  Case (a) is
> >>naturally handled by IS-IS, and the ISH isn't needed.  Case (b) isn't
> >>covered in IS-IS, and you can't use ISH PDUs to solve it -- because
> >>the ISH can only contain one NET, and it has to match the adjacency
> >>so you can't just send a bunch of them.  This was resolved for SONET
> >>NEs by the SIF; the router should advertise these as ES neighbors with
> >>path costs of 1.  (I argued for zero, but that didn't go over because it
> >>might have caused trouble with implementations that couldn't handle
> >>zero metrics anywhere outside pseudonode LSPs.)  Hopefully we don't need
> >>to go into that in an RFC!
> >>
> >>>Sorry for so many questions.
> >>
> >>Sorry for such long answers ;-)
> >>
> >>
> >>>Anyhow, we are going to have a choice; either we say that it is OK to
> >>>just ignore incoming ISHs, or we say that we must work if they are not
> >>>there but if they are then they must be processed.
> >>
> >>I think the thing to do is to state that prevalent implementations
> >>do not send ISHs on PTP links, and that an implementation is advised to
> >>bring up the adjacency anyway.  To do this, we must relax the rule in
> >>10589:1992+TC1:1993 that does not permit sending an IIH until an ISH
> >>has been received, and allow sending of the IIH when an IIH has been
> >>received, or for systems where connections to OSI end systems over
> >>PTP links are not supported, the IIH can be sent as soon as the link
> >>is up.
> >>
> >>I also think it may be appropriate to include a little history here,
> >>showing how 19589:1992 could reasonably be interpreted to allow
> >>sending IIHs before receiving ISHs, yet the rule in TC1 would not
> >>interoperate with this interpretation.  (I think that TC1, while
> >>well-intentioned, was unfortunately misworded.  It should have
> >>allowed sending an IIH after receiving one.)
> >>
> >>Regards,
> >>Jeff
> >>
> >>>Thoughts?
> >>>
> >>>Philip
>

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg