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

From: David Hudek <[email-masked]>
Date: Tue, 05 Jun 2001 14:38:45 -0700

Hi all,

I originally sent the following note to Jeff, and
he asked me to resend it to the wg email list.
Comments/clarifications/corrections/further discussion welcomed.

Thanks,
dave h

David Hudek wrote:
> 
> Hi Jeff...
> 
> I'm not sure if these sorts of questions/comments
> should go on the ISIS working group email list or
> be sent directly to the author... I'm just
> opting for the latter as a default :-)
> 
> I've started looking at draft-ietf-isis-wg-mib-04.txt (believe
> this is the latest?) and had a couple minor
> questions/comments concerning the IsisSummAddrEntry stuff...
> 
>     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?)
> 
>        My first thought was that only one is needed,
>        with extra error handling now required if we
>        allow two and they accidentally differ...
>        but perhaps a heterogeneous combination
>        makes sense and I just didn't see it?
> 
> 
>     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) (?)...
> 
>        Can there be a little more verbiage describing
>        exactly what the isisSummAddrAdminState
>        (which can take on values indicating L1, L2,
>        L1L2, and off) is supposed to indicate?
>        Perhaps something to indicate which end of the
>        leaking is contemplated (e.g., "into" vs. "out of")...
>        For instance, if it's "summaryl1", does that mean the
>        summarization is supposed to be applied when leaking
>        out of L1, or when leaking into L1? Basically,
>        in which direction is the filter applied?
>        I'm assuming "out of" is meant, but you know
>        what happens when one assumes :-)
> 
>        Also, is an L1L2 entry functionally the same
>        as an L1 entry and a separate L2 entry with
>        identical addr/mask?
>        (is it just there to save on an extra config step
>         or does it mean something different)?
>        If it's the same as a L1 and a L2, I'd personally
>        rather see the L1L2 removed and the two summaries
>        be made explicit, so they can be treated independently.
>        Else, if it was L1L2, and user decided they just
>        wanted L1, then they'd have to turn off L1L2
>        and then quickly add it back as L1, possibly causing
>        unnecessary churn in the LSPs as the summarization
>        state bounced.

         (of course, one could change the order, add the 
          L1 and then turn off the L1L2, but still...
          the semantics are a little unclear, as 
          mentioned next)

>        And you could get complaints about the treatment of
>        the same addr/mask in overlapping types if one was
>        turned off and the other on... which one wins?
>        For instance, if the user turned off L1L2 intending
>        that they both not summarize that addr/mask, but
>        they also had that addr/mask as an L1, then what
>        happens? I'm assuming that the L1 summarization
>        occurs (L1 on trumps L1L2 off)
>        but perhaps others would assume differently.
> 
>        (and a really *minor* nit... if there's not
>         a MIB convention that prohibits it, when naming
>         items with L and 1 next to each other,
>         could the capital L be used instead of lower case?
>         "l1" looks an awful lot like "11", while
>         "L1" is easily distinguished... personal opinion,
>         I think that summaryL1 looks just spiffy, while
>         summaryl1l2 at first glance looks like the
>         many-level-ISIS effort has gone on steroids
>         with over 1000 levels  :-) )
> 
> Thanks,
> dave h
> [email-masked]

Subject: Question/Comment on draft-ietf-isis-wg-mib-04.txt
From: David Hudek <[email-masked]>
To: [email-masked]
Date: Mon, 04 Jun 2001 20:23:30 -0700

Hi Jeff...

I'm not sure if these sorts of questions/comments
should go on the ISIS working group email list or
be sent directly to the author... I'm just
opting for the latter as a default :-)

I've started looking at draft-ietf-isis-wg-mib-04.txt (believe
this is the latest?) and had a couple minor 
questions/comments concerning the IsisSummAddrEntry stuff...

    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?)

       My first thought was that only one is needed,
       with extra error handling now required if we 
       allow two and they accidentally differ...
       but perhaps a heterogeneous combination
       makes sense and I just didn't see it?

    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) (?)...

       Can there be a little more verbiage describing
       exactly what the isisSummAddrAdminState 
       (which can take on values indicating L1, L2, 
       L1L2, and off) is supposed to indicate?
       Perhaps something to indicate which end of the
       leaking is contemplated (e.g., "into" vs. "out of")... 
       For instance, if it's "summaryl1", does that mean the 
       summarization is supposed to be applied when leaking 
       out of L1, or when leaking into L1? Basically,
       in which direction is the filter applied?
       I'm assuming "out of" is meant, but you know
       what happens when one assumes :-)

       Also, is an L1L2 entry functionally the same
       as an L1 entry and a separate L2 entry with 
       identical addr/mask?
       (is it just there to save on an extra config step
        or does it mean something different)?
       If it's the same as a L1 and a L2, I'd personally
       rather see the L1L2 removed and the two summaries
       be made explicit, so they can be treated independently.
       Else, if it was L1L2, and user decided they just
       wanted L1, then they'd have to turn off L1L2
       and then quickly add it back as L1, possibly causing 
       unnecessary churn in the LSPs as the summarization 
       state bounced.
       And you could get complaints about the treatment of
       the same addr/mask in overlapping types if one was
       turned off and the other on... which one wins?
       For instance, if the user turned off L1L2 intending
       that they both not summarize that addr/mask, but
       they also had that addr/mask as an L1, then what
       happens? I'm assuming that the L1 summarization
       occurs (L1 on trumps L1L2 off) 
       but perhaps others would assume differently.

       (and a really *minor* nit... if there's not
        a MIB convention that prohibits it, when naming
	items with L and 1 next to each other,
	could the capital L be used instead of lower case?
	"l1" looks an awful lot like "11", while
	"L1" is easily distinguished... personal opinion,
	I think that summaryL1 looks just spiffy, while
	summaryl1l2 at first glance looks like the
	many-level-ISIS effort has gone on steroids
	with over 1000 levels  :-) )

Thanks,
dave h
[email-masked]