Subject: RE: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04 .txt]

From: Jeff Parker <[email-masked]>
Date: Tue, 5 Jun 2001 16:04:31 -0400

> > ...[is] draft-ietf-isis-wg-mib-04.txt ... the latest?

Yup.

> >     a) Why two "type" entries, one for address and
> >        one for mask... are they not required to agree?
> >        (e.g., if the address is ipv4 type, then doesn't
> >         the associated mask also have to be ipv4 type?)

This is an issue with RFC 2851's InetAddress object.  This has 
been addressed in a recent draft that Juergen Schoenwaelder
pointed out, draft-ietf-ops-rfc2851-update-00.txt, which includes
provisions for a triple (Type, Address, MaskLen).
I will use this in version 05.  

> > 
> >     b) Assuming the summary addresses are for the
> >        purpose of prefix summarization when leaking
> >        routes up or down the levels (with leaking down
> >        now allowed via rfc 2966) (?)...

Point taken.  The original anticipated summarizing L1 
routes into L2.  I was trying to support the ability 
to summarize L1 routes into L1 as well, which some
vendors support.  If you are importing routes from
another protocol into IS-IS, you might wish to summarize
before announcing.

Any comments from the list about the relevance
of summaries from {L1, L2} into {L1, L2}?  
(That is, which of the four possibilities make sense)
Does it make sense to summarize L2 into L1?  

> >        Also, is an L1L2 entry functionally the same
> >        as an L1 entry and a separate L2 entry with
> >        identical addr/mask?

You raise a good point about controlling these.  The
question of what we should/should not support remains.  

> >         could the capital L be used instead of lower case?
> >         "l1" looks an awful lot like "11", while
> >         "L1" is easily distinguished... 
> >
> > [email-masked]

Many of these are easy to fix.  
I think there is a requirement that the first character 
of  an enumerated type be lower case (as below).  I 
suppose these could be spelled out as "level1..."
and "level2...".  Would that be any better?

- jeff parker
- axiowave networks

     isisISAdjNeighSysType OBJECT-TYPE
         SYNTAX INTEGER {
             l1IntermediateSystem(1),
             l2IntermediateSystem(2),
             l1l2IntermediateSystem(3),
             unknown(4)
             }

---

From: David Hudek <[email-masked]>
Date: Fri, 08 Jun 2001 13:41:57 -0700

> Jeff Parker wrote:

I'll take a stab at this...

Of the possible combinations {L1,L2} into {L1,L2},
I believe that L1->L2 and L2->L1 are already
specified (in rfc1195 and rfc2966) 

I'm not sure L1->L1 or L2->L2 makes sense?
At least, I can't find any specification for
L1->L1 or L2->L2 summarization in the ISIS rfcs.

As far as I know, only two of the four combinations
are "legal"

That brings up the question of other combinations,
though, which as far as I know, have been implementation
dependent?  Would it be a good or bad idea to
standardize them a bit and possibly include
them in the ISIS MIB? Such as summarizing other
protocols' routes when injecting/redistributing
them into a particular level of ISIS.
Say, one wanted to inject BGP routes into L2 ISIS,
but was willing to sacrifice some accuracy for
better scalability by summarizing those routes first.
I don't see a mechanism in the MIB for doing that?
One might have four summarization types: L1ToL2,
L2ToL1, OtherProtToL1, OtherProtToL2.
But that opens a can of worms... what if one
wanted different rules for different "other" protocols...
would there need to be separate types for each
and every other protocol to L1 and L2 ISIS...
or would just one type which applied to all
other protocols be satisfactory?

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

---

From: David Hudek <[email-masked]>
Date: Fri, 08 Jun 2001 14:10:43 -0700

There was discussion on another thread ("Summary Address")
that might affect the MIB as well...

In discussing how one ought to advertise a summary address,
a suggestion was made (paraphrasing here...)
to advertise the summary address using the lowest metric
from among those routes that matched the summary.

My understanding from rfc1195 (section 3.2) was that one should 
instead advertise the summary using a set metric which was 
manually configured (and the draft MIB has such a field...
the isisSummAddrDefaultMetric)

Actually, 1195 does use the word "may" in there somewhere :-)
so there's a fair amount of leeway in how folks implement it.

I was wondering if it might not be a good idea to make
it explicit how one was summarizing, and perhaps add to
the MIB either a control knob (telling ISIS how to
summarize:  a)use configured metric as specified in
the isisSummAddrTable, b)ignore it and aggressively use the 
smallest metric from among the routes which match,
or c)ignore it and conservatively use the largest metric
from among the routes which match), or alternatively a
read-only value in which the ISIS implementation just
tells which scheme it is using but cannot be told
to act differently.

I think a network administrator might be confused/upset
if they set the metric value in the table, assuming it
would be used, but then the implementations do something 
different. If neither the control knob nor the information 
field seem appropriate, perhaps the text surrounding
the metric field in the summary table should be
modified to say that this is only a suggested metric
and that implementations may do something different?

Thanks,
dave h