Subject: [Isis-wg] Draft-ietf-isis-layer2-04.txt

From: David Allan I <[email-masked]>
Date: Sat, 17 Apr 2010 05:32:03 -0400

I have to admit the IANA considerations table is very useful. But it highlights that this is an RFC no-one in their right mind would ever aspire to comply to... It documents extensions for 3 completely orthgonal technologies of which two are standards track, Ethernet & TRILL.  

No one implementation should be saddled with the bunch...I would advocate what I did at the start to address this now that it is pretty conclusive, separate drafts.

My 2 cents
D

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Sun, 18 Apr 2010 21:38:01 -0400

This is also my preference. Its so much simpler to have a single draft to
refer to that has the necessary changes for a single protocol. I fail to see
the upside?

Peter
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Allan I
Sent: Saturday, April 17, 2010 5:32 AM
To: [email-masked]
Subject: [Isis-wg] Draft-ietf-isis-layer2-04.txt

I have to admit the IANA considerations table is very useful. But it
highlights that this is an RFC no-one in their right mind would ever aspire
to comply to... It documents extensions for 3 completely orthgonal
technologies of which two are standards track, Ethernet & TRILL.  

No one implementation should be saddled with the bunch...I would advocate
what I did at the start to address this now that it is pretty conclusive,
separate drafts.

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

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Mon, 19 Apr 2010 10:59:39 -0400

In what working group is OTV being standardized?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Peter Ashwood-Smith
Sent: Sunday, April 18, 2010 9:38 PM
To: [email-masked]
Subject: Re: [Isis-wg] Draft-ietf-isis-layer2-04.txt

Peter
 
-----Original Message-----

My 2 cents
D

---

From: "David Michael Bond" <[email-masked]>
Date: Mon, 19 Apr 2010 21:28:34 -0400

The document itself is an individual submission, labeled as being produced
by the ethereal Network Working Group.
-David

                    David Bond                    
.~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~.
.University of New Hampshire                      .
.    - InterOperability Laboratory                .
.        Research and Development Software Eng.   .
.        Routing & Bridge Functions Consortiums   .
.    - Computer Science PhD Student               .
. 121 Technology Drive, Suite 2, Durham NH, 03824 .
.    (O) 1-603-862-3525     (M) 1-603-845-7514    .
.     http://mokon.net    http://iol.unh.edu      .
.~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~. 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Ashwood-Smith
> Sent: Monday, April 19, 2010 11:00 AM
> To: [email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Apr 2010 14:47:44 -0700

I disagree with Peter and David.

The "protocol" being modified/extended here is IS-IS (NOT TRILL, NOT
OTV, etc.). Defining the changes to the protocol necessary to support L2
in one document is highly desirable as it avoids duplication, ambiguity
(in cases where "similar but not identical" statements are made), and
encourages the use of a common encoding where similar information needs
to be advertised.

I can sympathize with the desire for a clear statement of what is needed
to support a particular L2 use case - but the proper way to address this
is to include profiles of the required functionality for each of the use
cases. (In ISO 10589 speak this would be analogous to the PICS sections
in Annex A - though I hope we can be a bit more straightforward than
that).

I think the addition of these profiles would be a desirable thing.

   Les

> Sent: Sunday, April 18, 2010 6:38 PM
> To: [email-masked]
> Behalf

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Wed, 21 Apr 2010 18:14:37 -0400

Your argument would only convince me if it made sense when replacing "IS-IS"
with "BGP" {or pick any other major protocol}. 

The reason for the IANA considerations sections in all the zillions of
drafts and RFC's out there is precisely to provide a mechanism for this
decoupling. 

I grant that TRILL is asking for much more than normally addressed by an
IANA considerations section but 802.1aq is not and the extreme difference in
complexity greatly concerns me.

Peter

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, April 21, 2010 5:48 PM
To: Peter Ashwood-Smith; [email-masked]
Subject: RE: [Isis-wg] Draft-ietf-isis-layer2-04.txt

   Les

---

From: David Allan I <[email-masked]>
Date: Thu, 22 Apr 2010 00:33:55 -0400

Les

What the IANA considerations section makes clear is that these are all compeltely orthogonal technologies. None do the same thing as there are significant differences in what each considers to be the service model, none manipulate the same datapath, and the current criteria for inclusion in the draft appears to be purely whimsy.... 

Suggesting commonality exists is purely aspriational, the facts do not bear this out....

My 2 cents
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, April 21, 2010 5:48 PM
To: Peter Ashwood-Smith; [email-masked]
Subject: Re: [Isis-wg] Draft-ietf-isis-layer2-04.txt

The "protocol" being modified/extended here is IS-IS (NOT TRILL, NOT OTV, etc.). Defining the changes to the protocol necessary to support L2 in one document is highly desirable as it avoids duplication, ambiguity (in cases where "similar but not identical" statements are made), and encourages the use of a common encoding where similar information needs to be advertised.

I can sympathize with the desire for a clear statement of what is needed to support a particular L2 use case - but the proper way to address this is to include profiles of the required functionality for each of the use cases. (In ISO 10589 speak this would be analogous to the PICS sections in Annex A - though I hope we can be a bit more straightforward than that).

   Les

> This is also my preference. Its so much simpler to have a single draft 
> to refer to that has the necessary changes for a single protocol. I 
> fail to see the upside?
> 
> Peter
> 
> Behalf Of David Allan I
> highlights that this is an RFC no-one in their right mind would ever 
> aspire to comply to... It documents extensions for 3 completely 
> orthgonal technologies of which two are standards track, Ethernet & 
> TRILL.
> 
> No one implementation should be saddled with the bunch...I would 
> advocate what I did at the start to address this now that it is pretty 
> conclusive, separate drafts.
> 
> My 2 cents
> D

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Apr 2010 22:36:20 -0700

Dave -

The draft is NOT (and SHOULD NOT be) a document about TRILL or OTV or
802.1aq. It is a document about the IS-IS protocol extensions required
to support Layer 2 use cases. I believe the introduction to the draft
clearly states that.

As far as commonality, all Layer 2 technologies make use of new PDUs -
which require the introduction of a second instance of the IS-IS Update
process- a change which is fundamental to the interoperability of the
protocol. In addition there are two TLVs which are used by all Layer 2
technologies.

There is divergence in regards to specific TLV/subTLV information. If
you want to argue for separate drafts for that information I am willing
to listen - although I don't see how it makes it easier for the authors,
readers, or implementors to spread this information over multiple
documents. But if you argue for that, recognize you will need four
documents - a base IS-IS Layer 2 protocol extension document and three
other Layer 2 technology IS-IS protocol specific documents.

  Les

> From: David Allan I [mailto:[email-masked]]
> Sent: Wednesday, April 21, 2010 9:34 PM
> To: Les Ginsberg (ginsberg); Peter Ashwood-Smith; [email-masked]
> What the IANA considerations section makes clear is that these are all
> compeltely orthogonal technologies. None do the same thing as there
are
> significant differences in what each considers to be the service
model,
> none manipulate the same datapath, and the current criteria for
> inclusion in the draft appears to be purely whimsy....
> 
> Behalf Of Les Ginsberg (ginsberg)
> OTV, etc.). Defining the changes to the protocol necessary to support
> L2 in one document is highly desirable as it avoids duplication,
> ambiguity (in cases where "similar but not identical" statements are
> made), and encourages the use of a common encoding where similar
> information needs to be advertised.
> 
> I can sympathize with the desire for a clear statement of what is
> needed to support a particular L2 use case - but the proper way to
> address this is to include profiles of the required functionality for
> each of the use cases. (In ISO 10589 speak this would be analogous to
> the PICS sections in Annex A - though I hope we can be a bit more
> straightforward than that).
>

---

From: Paul Unbehagen <[email-masked]>
Date: Thu, 22 Apr 2010 13:05:39 -0600

I think we're agreed that this document shouldn't be about any specific protocol.  And in saying that, then this should simply spec base TLV's for categorizing L2 topology info and then leave it to each protocol to specify the Sub-TLVs it needs in their own protocol drafts.  

Personally I agree with Peter and Dave in that a complete implementation draft makes more sense as this draft is very confusing as to what is required for just one of the protocols.

--
Paul

Second 802.1aq does NOT need to make use of new PDUs, it just needs some new TLVs.

---

From: David Allan I <[email-masked]>
Date: Thu, 22 Apr 2010 15:34:28 -0400

My point would be I don't need all the layer 2 technology specific documents, simply one of them, and as I've observed, the criteria for inclusion of future "layer 2" technologies is unclear, which also implies how this draft can progress is unclear...are future approaches also welcome, and shall we set a best before date for inclusion?

As it stands it is simply a snapshot of whatever was lying around at the time, including proprietary approaches. IMO that sort of stuff should be informational, not standards track...that is one issue, and the complete divergence of TLV/sub-TLV information still suggests to me the utility of a combined draft is questionable...

D

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, April 22, 2010 1:36 AM
To: David Allan I; Peter Ashwood-Smith; [email-masked]
Subject: RE: [Isis-wg] Draft-ietf-isis-layer2-04.txt

Dave -

The draft is NOT (and SHOULD NOT be) a document about TRILL or OTV or 802.1aq. It is a document about the IS-IS protocol extensions required to support Layer 2 use cases. I believe the introduction to the draft clearly states that.

As far as commonality, all Layer 2 technologies make use of new PDUs - which require the introduction of a second instance of the IS-IS Update
process- a change which is fundamental to the interoperability of the protocol. In addition there are two TLVs which are used by all Layer 2 technologies.

There is divergence in regards to specific TLV/subTLV information. If you want to argue for separate drafts for that information I am willing to listen - although I don't see how it makes it easier for the authors, readers, or implementors to spread this information over multiple documents. But if you argue for that, recognize you will need four documents - a base IS-IS Layer 2 protocol extension document and three other Layer 2 technology IS-IS protocol specific documents.

  Les

are
model,

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Apr 2010 13:26:08 -0700

> From: Paul Unbehagen [mailto:[email-masked]]
> Sent: Thursday, April 22, 2010 6:30 AM
> To: Les Ginsberg (ginsberg)
> Cc: David Allan I; Peter Ashwood-Smith; [email-masked]
> I think we're agreed that this document shouldn't be about any
specific
> protocol.  And in saying that, then this should simply spec base TLV's
> for categorizing L2 topology info and then leave it to each protocol
to
> specify the Sub-TLVs it needs in their own protocol drafts.
> 
> Personally I agree with Peter and Dave in that a complete
> implementation draft makes more sense as this draft is very confusing
> as to what is required for just one of the protocols.
> 

This statement is NOT consistent w the draft.
The draft clearly states that the GADDR TLV can ONLY be sent in MGROUP
PDU (see end of Section 2.2).

So as written all L2 technologies are required to use new PDUs.

One of the things I want to be sure we avoid is having discrepancies
between the L2 technologies in how the base protocol mechanisms are
used. I do not want GADDR TLVs to be restricted to MGROUP PDUs in one
technology but allowed in LSPs in other technologies - which is what
your statement above might be suggesting. This will create multiple
incompatible versions of the IS-IS protocol - which is unnecessary and
undesirable.

   Les

> Paul Unbehagen
> >> Suggesting commonality exists is purely aspriational, the facts do
> not
> >> bear this out....
> >>
> >> My 2 cents
> >> Dave
> >>

---

From: Paul Unbehagen <[email-masked]>
Date: Thu, 22 Apr 2010 15:05:00 -0600

Current SPB implementations are working in the wild just fine using TLVs, without the need of new PDU's.  From what I know of them the same ISIS is also doing regular IP as well.  

The handful of TLV's used for SPB don't carry Mcast info so placing them in a separate TLV as the other protocols do doesn't seem useful (I may be wrong) and that is another example of why these are all very different protocols.

My point was that the placement of the TLV in a new PDU was not requested, nor expected by the IEEE team working on 802.1aq.
--
Paul Unbehagen

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Thu, 22 Apr 2010 17:20:41 -0400

Les,

802.1aq puts all its TLV's in existing ISIS PDUs. The current layer2-04
draft is in error if it puts an 802.1aq TLV in one of the new TRILL PDU's ..
that's a simple mistake that we missed in our review and needs to be
corrected and I believe Don has already mentioned it, our apologies for
missing that mistake.

802.1aq has been very careful not to change anything in ISIS except for new
TLV's. Infact during the design debates lots of designers suggested
'improvements' and all were rejected in favor of simplicity. No new
addressing, no new PDU's. About the only change really is hello processing
that has some cases where an 802.1aq adjacency needs to be rejected, but
even then the rejection is for 802.1aq use of that link and does not say
anything about other protocols in IS IS that may want to still use that
link/adjacency.

Now granted, I can see some interesting uses of a non topology change PDU
and related logic, I can see that it would be very useful for IP address
distribution (and of course the proprietary OTV) also and should that become
a generic standard part of IS-IS and get some deployment soaking it makes
sense to look at ways to use it, however it was not the IEEE 802.1aq group's
intent to make any changes to IS-IS behavior except to use it as the
excellent topology and distribution protocol that it already is. 

We simply want to build our work on the IS-IS implementations that have
zillions of live deployment hours ... 

The other fact is that the switch routers that run these protocols have one
IS-IS stack, in many cases that IS-IS stack is being used in some pretty
impressive sized networks and frankly the idea of making substantial changes
to a single version just for L2, which is new, will not go over well. That
will likely require two completely parallel IS-IS stacks on the devices..
that's a development/test/deployment cost that is not something we want to
absorb at the moment.

Peter

specific
to

   Les

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Thu, 22 Apr 2010 17:19:40 -0500

Thanks Peter 

That is correct. We tried to use a common Trill PDU when that didn't work we designed our own it placed in with the MGROUP.  

Don  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Ashwood-Smith
Sent: Thursday, April 22, 2010 5:21 PM
To: 'Les Ginsberg (ginsberg)'; 'Paul Unbehagen'
Cc: [email-masked]
Subject: Re: [Isis-wg] Draft-ietf-isis-layer2-04.txt

Les,

802.1aq puts all its TLV's in existing ISIS PDUs. The current layer2-04 draft is in error if it puts an 802.1aq TLV in one of the new TRILL PDU's ..
that's a simple mistake that we missed in our review and needs to be corrected and I believe Don has already mentioned it, our apologies for missing that mistake.

802.1aq has been very careful not to change anything in ISIS except for new TLV's. Infact during the design debates lots of designers suggested 'improvements' and all were rejected in favor of simplicity. No new addressing, no new PDU's. About the only change really is hello processing that has some cases where an 802.1aq adjacency needs to be rejected, but even then the rejection is for 802.1aq use of that link and does not say anything about other protocols in IS IS that may want to still use that link/adjacency.

Now granted, I can see some interesting uses of a non topology change PDU and related logic, I can see that it would be very useful for IP address distribution (and of course the proprietary OTV) also and should that become a generic standard part of IS-IS and get some deployment soaking it makes sense to look at ways to use it, however it was not the IEEE 802.1aq group's intent to make any changes to IS-IS behavior except to use it as the excellent topology and distribution protocol that it already is. 

We simply want to build our work on the IS-IS implementations that have zillions of live deployment hours ... 

The other fact is that the switch routers that run these protocols have one IS-IS stack, in many cases that IS-IS stack is being used in some pretty impressive sized networks and frankly the idea of making substantial changes to a single version just for L2, which is new, will not go over well. That will likely require two completely parallel IS-IS stacks on the devices..
that's a development/test/deployment cost that is not something we want to absorb at the moment.

Peter

specific
to

This statement is NOT consistent w the draft.
The draft clearly states that the GADDR TLV can ONLY be sent in MGROUP PDU (see end of Section 2.2).

One of the things I want to be sure we avoid is having discrepancies between the L2 technologies in how the base protocol mechanisms are used. I do not want GADDR TLVs to be restricted to MGROUP PDUs in one technology but allowed in LSPs in other technologies - which is what your statement above might be suggesting. This will create multiple incompatible versions of the IS-IS protocol - which is unnecessary and undesirable.

   Les

---

From: David Ward <[email-masked]>
Date: Fri, 23 Apr 2010 10:18:04 -0700

Don -

At this point we are awaiting editor corrections and inclusion of your comments.  I believe it is coming shortly.

-DWard