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

From: Ayan Banerjee <[email-masked]>
Date: Tue, 03 Mar 2009 10:45:15 -0800

Hannes,

Please see responses inline.

Thanks,
Ayan

On 2/25/09 1:33 AM, "Hannes Gredler" <[email-masked]> wrote:

> Robert Raszuk wrote:
>> 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 ?
> 
> 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.
> 
>> MI separation may be very well needed within the L2 routing itself hence
>>  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.
> 

[AB] For the layer-2 systems that are being proposed we need to flood
unicast and multi-cast information. The multicast information is carried on
a separate database and uses information from the unicast database to
compute next hop information etc. In my response to Greg, we just discussed
that the splitting in different databases allows them to have their own set
of timers etc. We are proposing that all of this be carried in the single
instance since all the information belongs to the same instance for the
solution to work. MI can be used on top of this for other purposes as Robert
has pointed out. 

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

[AB] I believe that we are proposing to re-use the machinery that has been
developed and tested well. The extension simply creates a parallel multicast
database to behave in the similar fashion (for flooding purposes) as the
unicast database. 

[AB] Given that the draft proposed to have all of this in one single
instance, all the other extensions (from your other email) for example,
extended-lsp will apply. For example, if node A has two system ids, the
original S1 and the ext-is S2, it will follow the rules for the unicast
topology/database as currently defined. During the lookup of the
"ext-is"-multicast-lsps (i.e., S2-id-in-multicast-lsps) the unicast database
should return the correct result. It is the motivation of this draft to keep
everything within a single instance such that all other extensions can be
easily applied to them. This may not be explicit in the current version of
the draft, but we can make it more explicit.

> /hannes

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 Mar 2009 10:45:06 +0100

hi ayan,

> solution to work. MI can be used on top of this for other purposes as Robert

lets forget about MI at the moment -
the point that i do not understand is:
why does the multicast database information need to get carried in
some dedicated PDU ? an implementation can be written such that you
do have separate internal databases which its own timers etc.
why can't the multicast TLV not just "live" in a regular LSP PDU ?
in what respect are the flooding semantics of multicast data different
than unicast data.

> database to behave in the similar fashion (for flooding purposes) as the

can you explain why the exisiting LSP flooding vehicle is not good enough
for use of multicast data ? - what prevents us using LSP flooding
for L2 mcast routing ?

> the draft, but we can make it more explicit.

thats would be certainly a good thing, giving some better orientation.

tx,

/hannes

---

From: Ayan Banerjee <[email-masked]>
Date: Wed, 11 Mar 2009 13:06:43 -0700

Hannes, 

I believe that your queries below are what I had responded to in an earlier
email: 
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

The above will allow for other extensions to be applied to this Layer-2
instance as-is. I understand that this intent is missing in the current
draft, and we will update it appropriately.

Thanks,
Ayan

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 11 Mar 2009 23:07:32 +0100

hi ayan,

> I believe that your queries below are what I had responded to in an earlier

not really - you have some arguments which (most of them) are not correct.

 > flooding  Management separation of multicast group information

this does not require to rebuild the flooding infrastructure.
my point is that the existing flooding mechanism can be reused for that
purpose and still be fast. can you give some example why the exisiting
LSP flooding mechanisms cannot be used for rapid multicast join/leave
events. i am missing some substance here - how fast does it needs to be.
just stating: we need something new then all will be faster, does not feel
right to me. since this is (i hope) still a technical mailing list we should
start talking numbers, right ?

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

thats a dubious argument: what you will gain is storage space for another
374K of information. the extended LSP draft will give you 374K * N
storage space (N is number of sysids).
we have already an instrument to scale LSP space,
why re-inventing the wheel ? or do you see some value in combining
the mcast PDU with the LSP extension draft ? 374K * (N * 2) does not
sound overly attractive to me given the additional complexity
of rebuilding a flooding mechanism.

> Efficient SPF runs and multicast-attachment updates due to database

again a dubious argument:
doing efficient SPF runs is entirely an implementation matter.

if done right hopefully all the PDU data is properly parsed and
stored in some database. if you convey things in a different envelope
(mcast PDU) you do gain nothing - you have to parse the data anyway.

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

non reusing already hardened code is a concern to me and my customers.
it causes app. 3-4 years until fully inter operable solutions are
deployed in the field. if you expense this for no good reason then
i have to speak up. so far the IS-IS has been a incremental effort
(and that is the reason why protocol extensions so far only took
1-2 years to get working and fully interoperable.

/hannes