Re: Accept as WG doc?

Greg, 

Thanks much for your comments. Please see responses inline.

Ayan

On 2/25/09 10:09 AM, "gregory.cauchie <at> orange-ftgroup.com"
<gregory.cauchie <at> orange-ftgroup.com> wrote:

> Hi folks,
> 
> This draft seems to answer correctly the requirement for using IS-IS as a
> layer-2 routing protocol.
> 
> I have though one clarification question to the authors regarding the MAC-RI
> TLV (in 2.1) which is as a sub-TLV but also defined as directly carried in a
> L1 LSP. I think it is a "regular" TLV, right?

[AB] Thanks much for catching the error, will fix it in the next revision of
the draft.

> Furthermore, I was asking mysef why did you define some "root" TLVs. IINM,
> lots of TLVs defined in this draft are extending IS-IS to support multicast
> routing as it was made in OSPF with MOSPF and its type-6 LSA. And if I am
> still right, there is no definition in MOSPF of such "root" information to
> flood. Therefore I was wondering why did you choose to define such TLVs.
> 

[AB] In TRILL, a node may decide not to send packets on some of the "trees".
This could be based on some local policy. In this case, other nodes can save

Re: Accept as WG doc?

Hannes,

Please see responses inline.

Thanks,
Ayan

On 2/25/09 1:33 AM, "Hannes Gredler" <hannes <at> juniper.net> 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.
> 

I-D Action:draft-ietf-isis-layer2-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title           : Extensions to IS-IS for Layer-2 Systems
	Author(s)       : A. Banerjee
	Filename        : draft-ietf-isis-layer2-00.txt
	Pages           : 20
	Date            : 2009-03-03

This draft specifies the IS-IS extensions necessary to support multi-
link IPv4 and IPv6 networks, as well as to provide true link state
routing to any protocols running directly over layer 2.  While
supporting this concept involves several pieces, this document only
describes extensions to IS-IS.  We leave it to the systems using
these IS-IS extensions to explain how the information carried in
IS-IS is used.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-layer2-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________

IS-IS WG <at> IETF 74 (SF) -- CANCELED

Hi Folks,

As we've not received any slot requests we're going to cancel the  
upcoming isis-wg slot. We plan to meet in stockholm to at least  
discuss the consolidation of the layer2 draft with the parallel work  
being done in IEEE.

CHopps & DWard.

Re: Accept as WG doc?

hi ayan,

Ayan Banerjee wrote:
> On 2/25/09 1:33 AM, "Hannes Gredler" <hannes <at> juniper.net> 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

Re: Accept as WG doc?

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

On 3/6/09 1:45 AM, "Hannes Gredler" <hannes <at> juniper.net> wrote:

> hi ayan,
> 
> Ayan Banerjee wrote:
>> On 2/25/09 1:33 AM, "Hannes Gredler" <hannes <at> juniper.net> wrote:
>> 
>>> Robert Raszuk wrote:
>>>> Hi Hannes,
>>>> 
>>>>> the nice thing about MI is that it is a _generalized_ model

Re: Accept as WG doc?

hi ayan,

Ayan Banerjee wrote:
> I believe that your queries below are what I had responded to in an earlier
> email: 

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

> ­Rapid join/leave multicast group events to not impact unicast-spf/lsp
 > 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.

Re: Accept as WG doc?

I'd like to see a more thorough discussion of Hannes's points before  
accepting this.

So, no, for now anyway.

--John

On Feb 3, 2009, at 11:54 PM, 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
> Isis-wg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg

Re: Accept as WG doc?

Hi John,

May I ask what is the point of continuing the process of voting after WG 
chairs have already declared the draft 8 days ago to be a WG document ?

Cheers,
R.

See below:

Subject: [Isis-wg] l2isis is a WG doc
From: David Ward <dward <at> cisco.com>
Date: Wed, 25 Feb 2009 12:18:40 -0600
To: isis-wg <at> ietf.org
CC: trill-chairs <at> tools.ietf.org, Christian Hopps <chopps <at> rawdofmt.org>

Given the WG is now debating how to bring L2 routing into ISIS and there 
has been no dissent to work on the topic; it is now a WG item. There is 
an ongoing discussion on how to do it but, let's put the answer in the 
doc that was put forward:

http://tools.ietf.org/html/draft-ward-l2isis-04

Thanks

-DWard, CHopps

> I'd like to see a more thorough discussion of Hannes's points before 
> accepting this.
> 

Re: Accept as WG doc?

I hadn't noticed that. The substance of the comment stands in any  
case, that I would like to see those points addressed.

--John

On Mar 12, 2009, at 5:32 PM, Robert Raszuk <robert <at> raszuk.net> wrote:

> Hi John,
>
> May I ask what is the point of continuing the process of voting  
> after WG chairs have already declared the draft 8 days ago to be a  
> WG document ?
>
> Cheers,
> R.
>
>
> See below:
>
> Subject: [Isis-wg] l2isis is a WG doc
> From: David Ward <dward <at> cisco.com>
> Date: Wed, 25 Feb 2009 12:18:40 -0600
> To: isis-wg <at> ietf.org
> CC: trill-chairs <at> tools.ietf.org, Christian Hopps <chopps <at> rawdofmt.org>
>
> Given the WG is now debating how to bring L2 routing into ISIS and  
> there has been no dissent to work on the topic; it is now a WG item.  
> There is an ongoing discussion on how to do it but, let's put the  
> answer in the doc that was put forward:
>