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

From: Ayan Banerjee <[email-masked]>
Date: Thu, 12 Feb 2009 21:26:42 -0800

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 
 Management separation of multicast group information
 Increase LSP-ID space for large volumes of multicast information
 Efficient SPF runs and multicast-attachment updates due to database
separation 
 Inter-operability with older implementations is not of any concern

Please note that 
(a) ³Extending LSP space² draft can be used in addition to what is being
proposed. 
(b) ³Multiple instances² draft separates the databases. However, here the
multicast 
information is to be used in conjunction with the uni-cast information.

Thanks,
Ayan

 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:
 | 
 | http://tools.ietf.org/html/draft-ward-l2isis-04
 | 
 | Thanks
 | 
 | Chris, Dave
 | _______________________________________________
 | Isis-wg mailing list
 | [email-masked]
 | https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 25 Feb 2009 09:10:11 +0100

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][email-masked]
|    | [3]https://www.ietf.org/mailman/listinfo/isis-wg
|
| References
|
|    1. http://tools.ietf.org/html/draft-ward-l2isis-04
|    2. file://localhost/tmp/[email-masked]
|    3. https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Feb 2009 00:57:09 -0800

Hi Hannes,

 > 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.

> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
> 
>

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 25 Feb 2009 10:33:09 +0100

> in itself just one new application ?

i did not say _one_ application. i did say that we have a generalized
model for seperation. this could be N * L3 instances and M * L2 instances,
whatever you like without the need for a new protocol.

>  it seems natural to reserve it for it's real purpose.

to me MI's "real purpose" is to create a demux point between the existing
protocol machinery and applications which need a well-known
flooding mechanism. i do not find a contradiction in using
several MI instances for L2 routing.

> MI extensions within itself when needed.

and that is the problem - rather than re utilizing what has been built,
a new protocol is being built with all the learning/stabilization/interop
curve. it would be far easier for everyone to build upon MI rather than
reinventing protocol-infra machinery that is already around and working for
years.

/hannes