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

[Robert Raszuk <[e-mail]>]

Hi Hannes,

 > the nice thing about MI is that it is a _generalized_ model
 > for seperating databases on a per-application basis.

That is precisely a point. What makes you think that L2 routing would be 
in itself just one new application ?

MI separation may be very well needed within the L2 routing itself hence 
  it seems natural to reserve it for it's real purpose.

Proposed in this draft set of TLVs, sub-TLVs and multicast PDUs seems to 
build the base for new isis protocol applications which in turn may use 
MI extensions within itself when needed.

Cheers,
R.


> 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
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
> 
>