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

From: Les Ginsberg <[email-masked]>
Date: Mon, 11 Feb 2002 11:27:01 -0800

The wording associated with sending ISHs and IIHs was clarified in small,
but significant ways, in the ISO 10589:2001 draft. Those who are interested,
please read the relevant sections. 

It is still true that a strict interpretation of ISO 10589 requires an ISH
to be received before sending IIHs, and therefore a strictly conformant
implementation would never bring an adjacency up without first receiving an
ISH.

As has been discussed previously on this list, some IP only implementations
have chosen to not send ISHs and most implementations are "generous" enough
to respond to received IIHs even without first receiving an ISH. But, this
is not conformant to the only written specification - so I applaud Tony's
call for an RFC which documents this protocol change. Perhaps those who
chose to ignore the spec would volunteer to write such an RFC??

   Les

> -----Original Message-----
> From: Tony Li [mailto:[email-masked]]
> Sent: Monday, February 11, 2002 9:56 AM
> To: Jeff Learman
> Cc: Ken Larmer; Shankar Vemulapalli; Chan, Chung Ming;
> [email-masked]
> Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH
> 
> 
> 
>  | Bottom line, by my interpretation: an IS is required to 
> send an ISH,
>  | but it must not expect other routers to send one.
> 
> 
> Minimalist viewpoint: the number of end systems out there is 
> vanishingly
> small and growing smaller by the day.  The thought of an end 
> system at the
> end of a point-to-point link then decreases the numbers by 
> another three
> orders of magnitude.
> 
> This seems like work that could be avoided without dire 
> consequences.  IS's
> that wanted to support this certainly could, but the rest of us don't
> really gain by it...
> 
> An RFC that said so would be a fine thing...
> 
> Tony
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 12 Feb 2002 10:24:52 -0800

Les Ginsberg wrote:

> so I applaud Tony's

I applaud that, put me on the list of authors pls. who else?  ;-)

    thanks

    -- tony

---

From: Micah Bartell <[email-masked]>
Date: Tue, 12 Feb 2002 15:00:22 -0600

If we are going to be kicking out an RFC detailing delta's between the 
specs and standard implementations, I would think a general RFC covering 
best practices would be the way to go instead of one off RFCs for each one.

/mpb

---

From: Jeff Learman <[email-masked]>
Date: Tue, 12 Feb 2002 16:08:42 -0500

OK, I'll contribute text for the initial ISH thing, & you guys can throw
darts at it.  Stay tuned.

Anyone volunteer to be editor?

Anyone have a good list of things to include?  I know there has been
some discussion but I didn't ever see it get any serious traction.
It might be a good idea for people to suggest items to include and
we can harangue about that.

Regards,
Jeff

At 04:00 PM 2/12/2002, Micah Bartell wrote:
>If we are going to be kicking out an RFC detailing delta's between the specs and standard implementations, I would think a general RFC covering best practices would be the way to go instead of one off RFCs for each one.
>
>/mpb
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 12 Feb 2002 11:00:54 -0800

> we can harangue about that.

this discussion has been had on the list and privately, pls read archives,
I will not repeat all  the arguments again.

We strongly encourage RFC per change rather than a 'new 1195' that
will contradict 10859 and old 1195 possibly and take forever to finish

    thanks

    -- tony

---

From: Alex Zinin <[email-masked]>
Date: Tue, 12 Feb 2002 16:08:42 -0800

Tony,

> will contradict 10859 and old 1195 possibly and take forever to finish

I think one document spelling out the differences btw 10589
and running code would make much more sense.

Whether this should be as part of an update on 1195 (which at
least needs the TLV133 fix) or a separate document seems to be
an orthogonal issue to me...

Alex.