Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

From: "Manral, Vishwas" <[email-masked]>
Date: Fri, 4 Jan 2002 07:57:15 -0500

Mike,

Agreed as long as another IS does not impose its MaxAge value on anybody
else, we need not have the condition that I had earlier specified i.e.
Min(MaxAge) >= Max(MinLSPGEnInterval) + Max(proagation Delay)(this however
would cause the MaxAge value used to be the minimum of the MaxAge in the
domain), where Min and Max are functions over all routers. So only condition
now would be MaxAge >= MaxLSPGenInterval + propagation delay for any router.

Apart from the scentence that you rightly suggested needs to be removed, I
guess maybe table 2 page 35, which talks about Routing Architechtural
Constant and has MaxAge as one of them can have MaxAge removed(it sends a
wrong signal).

Thanks,
Vishwas

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: Friday, January 04, 2002 5:54 PM
To: Dave Katz
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

Let me just reinforce what Dave is saying here (as if that were needed :-)

The ONLY thing that matters is that the LSP gen interval for any particular 
LSP is less than the value which the originating router sets in the 
remaining lifetime field when it is generated. i.e. we need to ensure that 
the originator will refresh the LSP before its remaining lifetime value has 
been exhausted. Provided that constraint is met (with a reasonable amount 
of slop to take care of timing differences etc.) not only can different 
routers use different values for "MaxAge", but a router could (if it was 
bloody minded enough) use different values for different LSPs (provided it 
could remember when to refresh them)!

There is ABSOLUTELY no need for any other router to police the value of 
MaxAge, and as has been pointed out, to do so would be wrong.

Just as a historical note here, the original DECnet PhaseV specification 
(where maxAGE was truely an architectural constant) did require that an LSP 
with a remaining lifetime greater than Maxage (20 minutes) be treated as 
being corrupt. This was propagated into 10589 (see 7.3.16.3), where it says 
that

"If the value of Remaining Lifetime is greater than MaxAge the LSP shall be 
processed as if there were a checksum error."

This is reasonable if MaxAge really is fixed.

But I think most implementations (and certainly those which allow MaxAge to 
be varied) quitely ignore this requirement (as indeed they must). If 
anything needs documenting, it should simply be the deletion of this
sentence.

         Mike

At 10:44 30/12/2001 -0800, Dave Katz wrote:
>I haven't been paying a lot of attention to this conversation, but that
>never stopped me from commenting before.
>
>One of the nice things about ISIS (as compared to OSPF) is that there
>are very few things that are truly architectural constants (as in, if
>you don't use this value, the protocol won't work.)  Further, there
>are less settable parameters that must be coordinated between systems
>in order for the network to function.
>
>The LSP lifetime (along with the adjacency holding time) has the very
>nice property that everybody can pick different values and the network
>Just Works.  This has operationally saved people more times than I can
>count.
>
>Any system that makes judgement on the choice of values of these parameters
>set by another system is just plain broken.
>
>--Dave
>
>    From: "Manral, Vishwas" <[email-masked]>
>    Cc: "[email-masked]'" <[email-masked]>
>    Content-Type: text/plain;
>            charset="iso-8859-1"
>    Sender: [email-masked]
>    X-BeenThere: [email-masked]
>    X-Mailman-Version: 2.0rc1
>    Precedence: bulk
>    List-Help: <mailto:[email-masked]?subject=help>
>    List-Post: <mailto:[email-masked]>
>    List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
>            <mailto:[email-masked]?subject=subscribe>
>    List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
>    List-Unsubscribe:
<http://external.juniper.net/mailman/listinfo/isis-wg>,
<mailto:[email-masked]?subject=unsubscribe>
>    List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
>    Date: Fri, 28 Dec 2001 00:37:40 -0500
>
>    Les,
>
>    I get the point you are trying to make. The problem you say would
happen
>    whenever there is a diff in MaxAge in IS's in the domain(and the LSP's
for
>    some reason is not refreshed).
>
>    This is what I am trying to say. The MaxAge would be the value which
would
>    be put in a self LSP, as remaining lifetime when we are originating a
new
>    LSP. If the remaining life time is greater than MaxAge for some other 
> IS, it
>    should treat the stuff as if MaxAge(in the sense it should not drop 
> the LSP,
>    MIB ops on remaining lifetime shld give age as MaxAge(if any), SPF(age
>    value) etc), however it should start the purge(MaxAge) timer for that
LSP
>    with the value of "remaining lifetime" field(So remaining lifetime 
> would be
>    zero after remaining life time period). However this would cause the 
> MaxAge
>    field to be used as in the remaining lifetime and not as configured in
the
>    IS itself.(some problems/loopholes/against existing approach with this
>    approach??)
>
>    This way all people would purge the LSP at nearly the same time(so the
>    problem described would not arise).
>
>    Thanks,
>    Vishwas
>
>    -----Original Message-----
>    From: Les Ginsberg [mailto:[email-masked]]
>    Sent: Friday, December 28, 2001 10:29 AM
>    To: 'Manral, Vishwas'; Les Ginsberg; 'Jeff Parker'
>    Cc: IS-IS-WG (E-mail)
>    Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
>
>
>    Vishwas -
>
>    Makes no difference. From the point of view of the receiver of an LSP,
it
>    has no way of knowing what the value of LSP lifetime may be on the
>    originating IS since the remaining lifetime field gets modified, based
on
>    elapsed time, prior to flooding. All the receiver can say is that the
>    originating IS has a value for LSP lifetime which is >= the original
>    received remaining lifetime.
>
>    If an IS arbitrarily decreases the remaining lifetime of an LSP it has
>    received, then it is quite possible that the LSP will age out of the
local
>    database before the originating router regenerates that LSP. The
protocol
>    will eventually recover, but in order to do so the LSP will first be 
> purged,
>    causing an SPF to be run on all routers (or many of them anyway) with
this
>    LSP absent, and then the originating router will, on seeing the purged
>    version, regenerate that LSP, flood it, and a second SPF will be run on
>    every router. Reachability advertised in this LSP will temporarily 
> disappear
>    from the forwarding databases throughout the area/domain and then be
>    restored. This is highly undesirable.
>
>      Les
>
>
>    >
>    >
>    > Les,
>    >
>    > I meant "remaining lifetime" field in the LSP and not age(wrong use
of
>    > terminology on my part).
>    >
>    > So this is what I meant:-
>    >
>    > 1. If the remaining Lifetime is > MaxAge value in the router,
>    > treat the
>    > remaining lifetime as if it was MaxAge.
>    > 2. MaxLSPGenInt should be less than min value of MaxAge for
>    > all routers in
>    > the domain.
>    > 3. The difference(as pointed out) should be at least enough
>    > so that the LSP
>    > is propagated thruout the domain(so that no one purges the
>    > LSP before the
>    > new version reaches it).
>    >
>    > Thanks,
>    > Vishwas
>    >
>    > -----Original Message-----
>    > From: Les Ginsberg [mailto:[email-masked]]
>    > Sent: Friday, December 28, 2001 2:31 AM
>    > To: 'Manral, Vishwas'; 'Jeff Parker'
>    > Cc: IS-IS-WG (E-mail)
>    > Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
>    >
>    >
>    > >
>    > > Treating any LSP with age above Maxage could be done as if
>    > > age was MaxAge.
>    > > May be we need to recommend that all routers in a domain
>    > have the same
>    > > Maxage(and the value of MaxLSPGenInt should be less than the
>    > > value of the
>    > > smallest value of MaxAge in any router in the domain)value
>    > > for things to
>    > > work ok(and then we can treat all LSP's with age greater than
>    > > MaxAge as
>    > > MaxAge), we could raise a trap on getting an LSP with age
>    > greater than
>    > > MaxAge.
>    > >
>    >
>    > The change from an architectural constant to a configurable value was
>    > presumably made based on customer demand. To require, or even
>    > suggest, that
>    > an implementation treat an LSP received with a lifetime > the
>    > architectural
>    > constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to
do.
>    > Routers which did this could end up purging an LSP from their
database
>    > before the originating router's MaxLSPGenInt timer fired,
>    > which would cause
>    > unnecessary flapping. If you want to argue that the current "de facto
>    > standard" of making LSP lifetime configurable should be made
>    > invalid you
>    > will at least be addressing the issue directly - though I
>    > suspect you will
>    > get little support. Circumventing the issue by pretending the
>    > value is not
>    > configurable is unwise.
>    >
>    > It is also worth noting that, as you suggest, there is a necessary
>    > relationship between LSP lifetime and MaxLSPGenInt, namely:
>    >
>    > 1)MaxLSPGenInt must be less than LSPlifetime
>    > 2)(LSPlifetime - MaxLSPGenInt) should be large enough to
>    > allow propagation
>    > of the LSP throughout the area/domain before the old LSP ages out
>    >
>    > If LSP lifetime is modified from the "default" value of 1200
>    > seconds, it
>    > makes sense to change MaxLSPGenInt in a like manner.
>    >
>    >    Les
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Mon, 7 Jan 2002 09:53:11 -0500

> Jeff,
> 
> The object
>      isisCircSmallHellos OBJECT-TYPE
>          SYNTAX AdminState
>          MAX-ACCESS read-create
>          STATUS current
>          DESCRIPTION
>              "Can we send unpadded hellos on LAN circuits?  Off means
>              LAN Hellos must be padded."
>           DEFVAL { off }
>      ::= { isisCircEntry 26 }
> 
> says the DEFVAL should be such that we must send LAN Hellos 
> padded. However
> from the discussion 
> http://people.juniper.net/pipermail/isis-wg/2000/000300.html
> http://people.juniper.net/pipermail/isis-wg/2000/000305.html
> it seems padding isn't of much help. Wouldn't it be better to 
> change the
> DEFVAL to not off(on)?
> ...
> Vishwas

Vishwas -
	The standard requires padded hellos.  The introduction
of this variable is an admission that some people like to
run without padded hellos, but I don't see any reason to make
unpadded (small hellos) the default behavior.  

	Strong feelings from the list?

- jeff parker

---

From: Les Ginsberg <[email-masked]>
Date: Mon, 7 Jan 2002 23:37:33 -0800

(Sigh...somewhat against my better judgement...)

There are some folks who think the benefits of padding outweigh the
drawbacks - others feel the scale is tipped in the other direction. Whatever
your individual opinion on the matter, the fact is that the spec calls for
padding. If there is a strong consensus that the spec needs to be changed,
then a change to the spec should be formally written, whether as a
modification to the ISO spec or an IETF draft. (NO!! I am NOT proposing or
advocating this!!)

In the meantime, trying to use the MIB to override the spec is
inappropriate. Jeff had the right idea(scroll to the bottom and see) - I'm
on his side.

   Les

> From: Dave Katz [mailto:[email-masked]]
> Sent: Monday, January 07, 2002 10:26 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Ruder pragmatist--I won't be writing another one.  ;-)
> 
> I guess it makes sense to try to mirror best practice 
> (whatever that may
> be) for these things.  When all else fails, default to the 
> spec or flip
> a coin.
> 
> --Dave
> 
>    X-JNPR-Received-From: outside
>    Cc: [email-masked], [email-masked]
>    Date: Tue, 8 Jan 2002 00:22:40 -0500 
>    Content-Type: text/plain
>    X-OriginalArrivalTime: 08 Jan 2002 05:22:23.0671 (UTC) 
> FILETIME=[7402B470:01C19804]
> 
>    Dave,
> 
>    Right, but wouldn't it help new implementations if the 
> default was the value
>    desired from implementations? I although agree that not 
> all implementations
>    would follow the default as given in the MIB, and its a 
> not a big issue what
>    the default in this case should be.
> 
>    Thanks,
>    Vishwas
> 
>    From: Dave Katz [mailto:[email-masked]]
>    Sent: Tuesday, January 08, 2002 10:32 AM
>    To: [email-masked]
>    Cc: [email-masked]; [email-masked]
>    To put on my rude pragmatist's hat again, it doesn't 
> really matter a
>    whole lot in practice what the MIB says the default is, since the
>    default is whatever the implementation already does (and defaults
>    in general are notoriously difficult to change in practice.)
> 
>       Jeff,
> 
>       My idea was that if the padded hellos aren't really of 
> much use, and as
>    Dave
>       put it "essentially useless and creates lots of 
> unnecessary customer
>       service" wouldn't it be wise not to make it the default 
> value. We aren't
>       strictly following the specs anyway.
> 
>       -Vishwas
> 
>       From: Jeff Parker [mailto:[email-masked]]
>       Sent: Monday, January 07, 2002 8:23 PM
>       To: 'Manral, Vishwas'
>       Cc: IS-IS-WG (E-mail)
>       Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt
> 
> 
>       > Jeff,
>       > 
>       > The object

---

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 8 Jan 2002 04:02:57 -0500

Les,

But thats already happenning(MIB overriding the spec I mean). ISIS Hello
multiplier(one example I came across) is a "routing architectural constant"
according to the spec. The object

     isisCircLevelHelloMultiplier OBJECT-TYPE
         SYNTAX Integer32 (2..100)
         MAX-ACCESS read-create
         STATUS current
         DESCRIPTION
             "This value is multiplied by the corresponding HelloTimer
             and the result in seconds (rounded up) is used as the
             holding time in transmitted hellos, to be used by receivers
             of hello packets from this IS"
         REFERENCE "{ISIS.aoi iSISHelloTimer (45)}"
         DEFVAL { 10 }
     ::= { isisCircLevelEntry 7 }

tells its configureable. And with the way the MaxAge is used, we may require
MaxAge to be configureable too, that would again be a violation of the spec.
I guess this is a bigger issue than changing the value of DEFVAL.

What are ur views on a draft on ISIS for IP(I sent a mail regarding this
earlier, but no responses)?

Thanks,
Vishwas

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 1:08 PM
To: 'Dave Katz'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

   Les

---

From: Jeff Learman <[email-masked]>
Date: Tue, 08 Jan 2002 11:24:38 -0500

Vishwas,

I strongly recommend against changing the default for whether to
pad IIHs.  This will create interoperability problems between
implementations.

It's fine that some implementations allow the IIHs to not be padded
and to not check IIH padding.  However, the default should minimize
the number of things that must be configured to permit interoperability,
and implementations exist that check the padding as required by the
spec.

If we were starting from scratch, we might choose a different default,
but we're not.

Does the MIB allow independent control of whether IIHs are padded and
whether or not to check IIH padding?  If so, it might be reasonable to
have the default to "not check" (although, as Les says, this is debatable).
This is would not cause the interoperability problem that would be caused
by changing the way IIHs are transmitted.

Regards,
Jeff

>At 04:02 AM 1/8/2002, you wrote:
>>Les,
>>

---

From: Jeff Parker <[email-masked]>
Date: Tue, 8 Jan 2002 12:11:28 -0500

> Does the MIB allow independent control of whether IIHs are 
> padded and whether or not to check IIH padding?  

Jeff L.
	There is no knob to control checking paddding, 
as there is no counter, no Notification (Trap) 
defined to track that a peer is not padding, so
no behavior to modify. 
	My take is that interoperation is possible,
if not required, between those who pad and those
who do not, so there is no need for a standard
notification when the twain shall meet.   

	I have added this knob to control padding
to allow an administrator to set the behavior
when an implementation supports both.  
	While I think it is important to show the
right value for the padding setting (that is,
the MIB variable should be present and readable)
I don't think it is required that an implementation
support the unpadded version.  I've tried to capture
that in a revised Description clause, below.  This
does give preference to the padded behavior, which 
should be supported for the reasons you laid out in
the comments I edited out.  

- jeff parker

     isisCircSmallHellos OBJECT-TYPE
         SYNTAX AdminState
         MAX-ACCESS read-create
         STATUS current
         DESCRIPTION
             "Can we send unpadded hellos on LAN circuits?  Off means
              LAN Hellos must be padded.
              Implementations should allow the administrator to read
              this value.  An implementation need not be able to
              support unpadded hellos to be conformant."
          DEFVAL { off }
     ::= { isisCircEntry 21 }
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 8 Jan 2002 12:58:02 -0500

Jeff L.,

It is exactly this reason I think a document of "Best Current Practices" is
required(and am unable to see why anyone would be against one).

The Spec says that MaxAge is an architectural constant, however
implementations making assumptions based on that would be broken. Padded IIH
Hello's(it seems to me - as well as from archives) don't exactly serve their
purpose, yet not implementing could lead to interoperability problems as
some implementations check the padding.

This itself sounds reason enough(to me) to document the best current
practices, if not the the "ISIS for IP" document. I am ready to raise the
issues/put forward a document for the purpose(if the list thinks its worth
the effort) and am sure there will be more people interested in helping with
the issues/document.

So wouldn't the BCP for sending IIH Hello's be that we send padded Hello's
till the adjacency comes UP(in case padding needs to be done). Also
shouldn't the behaviour for new implementations be not to check padding, or
would we still want padding to be checked in some cases?

Thanks a lot for the information,
Vishwas

-----Original Message-----
From: Jeff Learman [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 9:55 PM
To: Manral, Vishwas
Cc: [email-masked]
Subject: Fwd: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

Vishwas,

Regards,
Jeff

---

From: Jeff Learman <[email-masked]>
Date: Tue, 08 Jan 2002 13:41:56 -0500

I personally found padding to be extremely useful, but for reasons
that apply to developers rather than customers.  At my previous job
at ONE, we ported our ISIS to a variety of platforms.  It was always
very helpful that no special test was required to verify that the LAN
drivers & interfaces supported full 1500 byte frames (and surprising
how often, even in big brand name equipment), they didn't.  Of course,
this doesn't apply to consumers, as this kind of thing shouldn't vary
for a given platform/product.

On a simple LAN, big IIHs don't help much but shouldn't hurt much either.
In complex cases where MTU sizes aren't consistent (e.g., using ATM or
certain bridging cases), I would think it is helpful to know that a link
isn't what you think it is.  But some people with more experience than I
have think that it's better to let the routing protocol work, and if big
packets don't work, customers will naturally focus on that problem rather
than the routing protocol.  They have a good point.

I'm sure I oversimplified the cases; I don't have a strong opinion
on whether checking should happen by default or not.  In any case, it's
an issue that might merit being included in an informational RFC, as
well as a warning that MaxAge is not implemented as an architectural
constant in some implementations.  (Need we say more about that?)

It would certainly be interesting to see a list of potential issues.

Regards,
Jeff

---

From: Jeff Learman <[email-masked]>
Date: Tue, 08 Jan 2002 13:45:17 -0500

Sounds good to me, Jeff.

Jeff L