Re: [Isis-wg] Accept as WG doc?

[Hannes Gredler <[e-mail]>]

re-sending as it did not yet appear on the isis-wg list.

On Thu, Feb 12, 2009 at 09:26:42PM -0800, Ayan Banerjee wrote:
|    Hannes,
|    We propose to carry multicast information in a new Multicast-Group PDU
|    to address:
|     -Rapid join/leave multicast group events to not impact
|    unicast-spf/lsp flooding

well, you need to get your state across somehow - a different envelope
does not give you more processing speed. also different MI instances
may have different semantics when or if to run SPF.

|     -Management separation of multicast group information

in the MI-draft we can key databases using the MI-ID.

|     -Increase LSP-ID space for large volumes of multicast information

that problem has been solved using the LSP-ext draft

|     -Efficient SPF runs and multicast-attachment updates due to database
|    separation

can get done by virtue of a seperate MI-ID.

|     -Inter-operability with older implementations is not of any concern

thats not the point -
i do care about a protocol machinery that took 10+ years to harden.
i do see no sense in redoing that dance for no additional gain.

|    Please note that
|    (a) "Extending LSP space" draft can be used in addition to what is
|    being proposed.

how?  - do you have plans to support the additional flavours of
ext-is reach in the mcast PDUs ? - how do you connect the sysids
together ? this has not been mentioned in the draft.

|    (b) "Multiple instances" draft separates the databases. However, here
|    the multicast
|    information is to be used in conjunction with the uni-cast
|    information.

this is a matter of defininng the semantics of a given MI-ID.
just define a well-known MI-ID for L2 multicast and you are done.
and we can re-use the machinery which already exists.

--

so far the IS-IS protocol standards work has been an incremental effort.

with this draft already proposed and agreed upon solutions for getting
the functionality of (database seperation, applications other than IP routing etc.)
LSP space scaling - are tossed/made obsolete. - and there is no obvious reason for it.

--

the nice thing about MI is that it is a _generalized_ model
for seperating databases on a per-application basis. without redoing
the flooding infrastructure -IMO we should just build on that and should
not create confusion by ad-hoc usage of additional unnecessary PDU types
for doing the very same thing (keying databases).

adding new PDU types is not just a per-database key - it requires
redoing all the infrastructure for flooding, retransmission,
parsing etc.


i would not like the document progress as a WG-item until these concerns
are being addressed.

/hannes

|     hi david, et al,
|
|     may i ask why there is need for dedicated PDU types ?
|
|     i feel a bit of discomfort adding a set of new PDU types
|     which only cover existing functionality, just because of
|     of extending or seperating LSP space. it is my view that
|     we already have vehicles to address that.
|
|     two (hard) questions:
|
|     1. why is the "multiple instances" draft not good enough
|        seperating the different databases ? it seems like
|        we are getting down the road of PDU-type being
|        a functional database multiplexer.
|
|     2. why is the "extending LSP space" draft not good enough
|        if LSP space shortage is of concern ?
|
|     /hannes
|
|     On Tue, Feb 03, 2009 at 03:54:17PM -0600, David Ward wrote:
|     | All -
|     |
|     | Please let us know if you believe this document should be accepted
|    as
|     | a WG document:
|     |
|     | [1]http://tools.ietf.org/html/draft-ward-l2isis-04
|    |
|     | Thanks
|     |
|     | Chris, Dave
|     | _______________________________________________
|     | Isis-wg mailing list
|     | [2][e-mail]
|    | [3]https://www.ietf.org/mailman/listinfo/isis-wg
|
| References
|
|    1. http://tools.ietf.org/html/draft-ward-l2isis-04
|    2. file://localhost/tmp/[e-mail]
|    3. https://www.ietf.org/mailman/listinfo/isis-wg