Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

From: "Dhananjaya Rao (dhrao)" <[email-masked]>
Date: Tue, 4 May 2010 15:45:02 -0700

Hi folks,

We're just catching up on the discussions on the mailing list regarding
the L2 IS-IS draft-ietf-isis-layer2-04.txt. As the authors of OTV,
we'd like to clarify any doubts or concerns regarding the extensions
used by OTV.

Briefly, OTV uses the L2 IS-IS extensions being defined to provide a
solution for interconnecting datacenter networks. An I-D describing
the solution has been recently published at
http://tools.ietf.org/html/draft-hasmit-otv-00.

OTV shares along with TRILL/802.1aq several of the PDU/TLVs that
have been defined in this draft. There are of course a few additional
sub-TLVs defined specifically for OTV:

- A couple of hello extensions to advertise L2 site membership and
  capabilities.
- A group membership sub-TLV to advertise multicast source information.

The solution is already being deployed in several enterprise networks
and a final product with this solution is shipping soon. Given the
multiple technologies using L2 IS-IS, we'd like to ensure the extensions
and codepoints are published in a common document to aid interoperable
implementations.

Please let us know if you have any questions.

Thanks,
-Dhananjaya (for the authors)

>
>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, et al.
>	Filename        : draft-ietf-isis-layer2-05.txt
>	Pages           : 60
>	Date            : 2010-04-30
>
>This document 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-05.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.
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-isis-layer2-05.txt>

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Tue, 4 May 2010 21:11:21 -0500

Hi Dhananjaya

It is rather unprecedented to have material published in a WG document before it is in an individual draft and there is a consensus to add it. 

So for the changes for OTV they really should go in an individual draft and be discussed on their own merits.  

Do you and your authors agree? 

Don 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhananjaya Rao (dhrao)
Sent: Tuesday, May 04, 2010 6:45 PM
To: [email-masked]
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Hi folks,

We're just catching up on the discussions on the mailing list regarding the L2 IS-IS draft-ietf-isis-layer2-04.txt. As the authors of OTV, we'd like to clarify any doubts or concerns regarding the extensions used by OTV.

Briefly, OTV uses the L2 IS-IS extensions being defined to provide a solution for interconnecting datacenter networks. An I-D describing the solution has been recently published at http://tools.ietf.org/html/draft-hasmit-otv-00.

OTV shares along with TRILL/802.1aq several of the PDU/TLVs that have been defined in this draft. There are of course a few additional sub-TLVs defined specifically for OTV:

The solution is already being deployed in several enterprise networks and a final product with this solution is shipping soon. Given the multiple technologies using L2 IS-IS, we'd like to ensure the extensions and codepoints are published in a common document to aid interoperable implementations.

Thanks,

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

---

From: Hasmit Grover <[email-masked]>
Date: Tue, 4 May 2010 20:17:27 -0700

Donald,

As per draft-ietf-isis-layer it's intent is to capture the IS-IS extensions used by protocols running over L2. Like other protocols mentioned in the draft, OTV is also an L2 protocol which is using some of the TLVs mentioned in the draft. It is really important that all the IS-IS TLV codepoints are captured in a single document so that different implementations can inter-op with each other. 

-Hasmit

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Tue, 04 May 2010 23:58:48 -0400

The reason we all go to standards bodies is to contribute/debate/participate
in the evolution of the Internet.

I've been able to debate/participate openly with the Trill folks over the
last few years, they publish minutes, have an email list, regular meetings
etc. etc.

I've been able to debate openly with the IEEE 802.1aq folks over the last
few years, minutes, email lists, regular meetings etc.

Please explain to me where and when I've had the opportunity to debate OTV
and why that is not a problem?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hasmit Grover
Sent: Tuesday, May 04, 2010 11:17 PM
To: Fedyk, Donald (Don)
Cc: [email-masked]
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Donald,

As per draft-ietf-isis-layer it's intent is to capture the IS-IS extensions
used by protocols running over L2. Like other protocols mentioned in the
draft, OTV is also an L2 protocol which is using some of the TLVs mentioned
in the draft. It is really important that all the IS-IS TLV codepoints are
captured in a single document so that different implementations can inter-op
with each other. 

-Hasmit

On May 4, 2010, at 7:11 PM, Fedyk, Donald (Don) wrote:

> Hi Dhananjaya
> 
> It is rather unprecedented to have material published in a WG document
before it is in an individual draft and there is a consensus to add it. 
> We're just catching up on the discussions on the mailing list regarding
the L2 IS-IS draft-ietf-isis-layer2-04.txt. As the authors of OTV, we'd like
to clarify any doubts or concerns regarding the extensions used by OTV.
> Briefly, OTV uses the L2 IS-IS extensions being defined to provide a
solution for interconnecting datacenter networks. An I-D describing the
solution has been recently published at
http://tools.ietf.org/html/draft-hasmit-otv-00.
> 
> OTV shares along with TRILL/802.1aq several of the PDU/TLVs that have been
defined in this draft. There are of course a few additional sub-TLVs defined
specifically for OTV:
> The solution is already being deployed in several enterprise networks and
a final product with this solution is shipping soon. Given the multiple
technologies using L2 IS-IS, we'd like to ensure the extensions and
codepoints are published in a common document to aid interoperable
implementations.

---

From: Hasmit Grover <[email-masked]>
Date: Tue, 4 May 2010 21:01:28 -0700

I am not proposing that we should not debate OTV TLVs and question their existence. We are open to any questions and concerns regarding the OTV TLV.

-Hasmit

On May 4, 2010, at 8:58 PM, Peter Ashwood-Smith wrote:

> Of Dhananjaya Rao (dhrao)

---

From: "Dhananjaya Rao (dhrao)" <[email-masked]>
Date: Tue, 4 May 2010 22:04:46 -0700

Hi Don,

>From: Fedyk, Donald (Don) [mailto:[email-masked]] 
>Sent: Tuesday, May 04, 2010 7:11 PM
>To: Dhananjaya Rao (dhrao); [email-masked]
>Subject: RE: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt
>
>Hi Dhananjaya
>
>It is rather unprecedented to have material published in a WG 
>document before it is in an individual draft and there is a 
>consensus to add it. 

There definitely wasn't any intent to bypass WG precedent. We've not
tracked all the progress on the draft closely, but our understanding
was that this draft was incorporating together the different extensions.
Since OTV was using the existing ones and only needed a couple of
TLVs, we requested the addition of the extra TLVs. This probably could
have been done on the list.

>
>So for the changes for OTV they really should go in an 
>individual draft and be discussed on their own merits.  
>

While putting them in a separate draft may help avoid any perceived
contravention of protocol, we do feel that it would serve the L2-ISIS
implementations better if the extensions were published in one
document.

Reading through the archives, I see that the chairs have indicated that
all the L2 extensions will undergo expert review. I would hope
that the merits of the additional extensions can be discussed as
part of this process. We would be happy to participate.

Regards,
-Dhananjaya

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Dhananjaya Rao (dhrao)
>We're just catching up on the discussions on the mailing list 
>regarding the L2 IS-IS draft-ietf-isis-layer2-04.txt. As the 
>authors of OTV, we'd like to clarify any doubts or concerns 
>regarding the extensions used by OTV.
>
>Briefly, OTV uses the L2 IS-IS extensions being defined to 
>provide a solution for interconnecting datacenter networks. An 
>I-D describing the solution has been recently published at 
>OTV shares along with TRILL/802.1aq several of the PDU/TLVs 
>that have been defined in this draft. There are of course a 
>few additional sub-TLVs defined specifically for OTV:
>
>The solution is already being deployed in several enterprise 
>networks and a final product with this solution is shipping 
>soon. Given the multiple technologies using L2 IS-IS, we'd 
>like to ensure the extensions and codepoints are published in 
>a common document to aid interoperable implementations.
>

---

From: John E Drake <[email-masked]>
Date: Wed, 5 May 2010 04:21:04 -0700

+1

> Of Peter Ashwood-Smith
> Sent: Tuesday, May 04, 2010 8:59 PM
> To: 'Hasmit Grover'; 'Fedyk, Donald (Don)'
> Cc: [email-masked]
> and

---

From: Paul Unbehagen <[email-masked]>
Date: Wed, 5 May 2010 05:29:04 -0600

Agree with Peter as well.

--
Paul Unbehagen

from my iPhone

On May 5, 2010, at 5:21 AM, John E Drake <[email-masked]> wrote:

>> captured in a single document so that different implementations can  
>> inter-
>> op
>> with each other.
>>
>> -Hasmit
>>
>>> document
>>> So for the changes for OTV they really should go in an individual  
>>> draft
>> and be discussed on their own merits.
>>>
>>> regarding
>> we'd
>> like
>>> have
>> been
>>> networks
>>>> these

---

From: David Allan I <[email-masked]>
Date: Wed, 5 May 2010 07:58:47 -0400

Hi Dhananjaya:

I'm not sure what you are clarifiying...other than this is a proprietary technology and you want to document it in standards. Fine, there is a process, which to date has been circumvented. 

The motivation for standardization is to broaden the addressable market for a technology. But when I look at this situation and your remarks as a competitor, what I see is:

1) You already have at least an 18 month implementation lead on any competitior, anyone choosing to build this starting now would likely be 3 years behind you by the time they could ship product. Under the circumstances I doubt ANYONE is rushing out to interoperate with you.

2) You seem to think your proprietary technology should appear in a standards track document providing you with the alleged cachet of peer review and ultimately a real RFC to point to. IMO that is a significant marketing advantage as it produces the illusion of it being an industry initiative when in fact it isn't. Ironically all it WILL be is a meaningless information schema. There is no guarantee a document will exist that will ever tell you what to do with it, except by mining expired drafts, which means it is not really a living technology. What IANA would reference in allocating the code points is a good question.

3) If the WG actually requires demonstrated interoperability to get to RFC, for the reasons outlined in 1 the rest of us likely will be held up waiting for you to produce a competitor. And when there is no standards track document defining WHAT to do with the TLVs, what constitutes interoperability?

So WHY the IETF should grant you a fast track to broadening the addressable market for your proprietary technology, allow OTV to gate process for legitimate standards initiatives, and dignifying OTV as if it was a product of the IETF completely escapes me. Why you should think this draft is an appropriate vehicle to document a part of your proprietary technology is either incredibly naieve or incredibly disingenuous...

Meanwhile the rest of us expect a level playing field...

My 2 cents
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhananjaya Rao (dhrao)
Sent: Tuesday, May 04, 2010 6:45 PM
To: [email-masked]
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Hi folks,

Thanks,

---

From: Ralph Droms <[email-masked]>
Date: Wed, 5 May 2010 08:07:19 -0400

Which of TRILL, IEEE 802.1ag and OTV use each of the PDUs defined in  
draft-ietf-isis-layer2-05.txt?  Is it possible to devise an  
applicability or usage table, similar to the table for TLVs in section  
5, for the new PDUs?

- Ralph

---

From: John E Drake <[email-masked]>
Date: Wed, 5 May 2010 05:21:57 -0700

Ralph,

I think the point is that unlike TRILL, and IEEE 802.1aq, OTV is proprietary - nobody other than its designers has any idea how it works.

Publishing a few of its TLVs does absolutely nothing regarding interoperability.

Thanks,

John

> Of Ralph Droms
> Sent: Wednesday, May 05, 2010 5:07 AM
> To: [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 5 May 2010 08:36:19 -0400

John - I understand that OTV is a proprietary protocol.  My questino  
was asked to find out about applicability of those PDUs - which  
protocols require which PDUs, and what is the motivation for including  
each of those PDUs in draft-ietf-isis-layer2-05.txt.

- Ralph

On May 5, 2010, at 8:21 AM 5/5/10, John E Drake wrote:

> Ralph,
>
> I think the point is that unlike TRILL, and IEEE 802.1aq, OTV is  
> proprietary - nobody other than its designers has any idea how it  
> works.
>

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Wed, 5 May 2010 08:19:50 -0500

Hi Hasmit 

That was not the question.  We did not get to discuss whether OTV extensions were to be included.
Nothing prevents you from reusing some of the TLVs in the draft. 
It is really important that IS-IS TLV code points are unique that is why we have ISO and IANA.  

Regards,
Don 

-----Original Message-----
From: Hasmit Grover [mailto:[email-masked]] 
Sent: Tuesday, May 04, 2010 11:17 PM
To: Fedyk, Donald (Don)
Cc: Dhananjaya Rao (dhrao); [email-masked]
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Donald,

-Hasmit

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 5 May 2010 09:28:46 -0400

Hi Ralph,

The existing table in draft-ietf-isis-layer2-05 in Section 5, split across
pages 56 and 57, has an "LSP" column and an "MGROUP LSP" column. By
implication, those protocols indicated in the TRILL/IEEE/OTV column for an
TLV/sub-TLV with an X in the MGROUP LSP column are specified in that draft
as using the MGROUP set of PDUs. However, I, along with many others, think
the MGROUP cluster of three PDUs is unnecessary and should just be
eliminated from the draft.

That leaves three other PDUs, the TRILL Hello, MTU-probe, and MTU-ack.

Not surprisingly, the "TRILL Hello" PDU is used by TRILL but it is a
separate PDU only out of an abundance of caution. TRILL implementations
never use the "LAN Hello" used at Layer 3 and non-TRILL implementations of
IS-IS never issue a TRILL Hello. (Both use the same P2P Hello on P2P links.)
Since TRILL and Layer 3 frames are distinguished by using different
multicast addresses and by using Area Addresses which are in practice, if
not in theory, completely disjoint. Thus there are already 2 means of
separating "LAN Hellos" frames from "TRILL Hellos" and, as I say, using a
different PDU number for TRILL Hellos was suggested only out of an abundance
of caution.

The MTU-probe and MTU-ack provide a simple one-hop request-response way to
test link MTU. Implementation of MTU-probe is optional but a TRILL
implementation receiving an MTU-prove must respond with an MTU-ack. MTU is a
loop safety consideration for TRILL. This MTU facility, and the ability to
report MTUs with the extended IS reachability MTU sub-TLV, could also be
used, for example, by Layer-3 IS-IS to collect information on which to base
traffic engineered routes meeting some minimum MTU requirement.

Thanks,
Donald

On Wed, May 5, 2010 at 8:36 AM, Ralph Droms <[email-masked]> wrote:

> John - I understand that OTV is a proprietary protocol.  My questino was
> asked to find out about applicability of those PDUs - which protocols
> require which PDUs, and what is the motivation for including each of those
> PDUs in draft-ietf-isis-layer2-05.txt.
>
> - Ralph
>
>
>> proprietary - nobody other than its designers has any idea how it works.
>>

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Wed, 05 May 2010 17:35:57 -0400

You have conveniently skipped the difficult part of standardization and
jumped right to TLV formats where you are now willing to debate the
organization of the bits and bytes. That's not the point.

For example, where was the debate held openly about VPLS v.s. IP multicast
etc. held , about IS-IS v.s OSPF, or even BGP for carriage .. and no lets
not debate it here.

OTV may well be a very useful technique, but unless you expose it to proper
external debate it is not a standard and should not be part of a standard
document.

What I suggest is that you simply ask for some reserved code points the way
most proprietary stuff is done, and then produce an informational draft.
Nobody will object to that.

Then take an open draft to L2VPN get it accpeted and invite other authors to
join. I for one would be happy to work with you but only as a real standard
and debated/accepted in a relevant working group.

Peter

-----Original Message-----
From: Hasmit Grover [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 12:01 AM
To: Peter Ashwood-Smith
Cc: 'Fedyk, Donald (Don)'; [email-masked]
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

I am not proposing that we should not debate OTV TLVs and question their
existence. We are open to any questions and concerns regarding the OTV TLV.

-Hasmit

> captured in a single document so that different implementations can
inter-op

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Wed, 5 May 2010 14:45:56 -0700

Hi David,

The intent is to open the technology for broad implementation and with
it the addressable market and vendor opportunity. In this vein, the goal
is to avoid overlap in the future use of the TLV/codepoint space by
having the ISIS WG's use of these TLVs formally documented, fully
disclosed and (hopefully) acknowledged/agreed upon. 

Rather than seeing an early implementation as a competitive threat, I
would look at it as an opportunity to capitalize on the existing ramp-up
investment/learning curve and reduce your time to market, costs and
overall risk of a solution like OTV. 

It is important that there is an authoritative registry of TLVs and
codepoints so that conflicts are avoided. I think as a WG that can be
achieved and it is far from useless information. 

There is a draft submitted explaining what to do with these TLVs for
OTV. If it is not satisfactory, it can be improved, but that is a task
for a different WG. The request from the ISIS WG is simple: document the
TLVs/codepoints formally and in a timely manner. In the same way as OTV
leverages TLVs that were originally conceived for TRILL, there is
potential for the additional TLVs to play in other solutions beyond OTV.
So beyond this tactical argument, my opinion is that these TLVs could be
strategically generalized and therefore belong in the WG.

We are coming to the WG because the TLVs will be used in a shipping
implementation, they are being disclosed to the community and this
information needs to be discussed and documented. Mine is but one
opinion, it is ultimately up to the WG, but we are disclosing
information that has an impact on future activities in the ISIS space. I
would think the WG wants to do the right thing and accommodate for
progress and innovation while maintaining control of the TLV and
codepoint allocation landscape.

Regards,

-v

From: David Allan I <[email-masked]>

Date: May 5, 2010 4:58:47 AM PDT

To: "Dhananjaya Rao (dhrao)" <[email-masked]>, "[email-masked]"
<[email-masked]>

Hi Dhananjaya:

I'm not sure what you are clarifiying...other than this is a proprietary
technology and you want to document it in standards. Fine, there is a
process, which to date has been circumvented. 

The motivation for standardization is to broaden the addressable market
for a technology. But when I look at this situation and your remarks as
a competitor, what I see is:

1) You already have at least an 18 month implementation lead on any
competitior, anyone choosing to build this starting now would likely be
3 years behind you by the time they could ship product. Under the
circumstances I doubt ANYONE is rushing out to interoperate with you.

2) You seem to think your proprietary technology should appear in a
standards track document providing you with the alleged cachet of peer
review and ultimately a real RFC to point to. IMO that is a significant
marketing advantage as it produces the illusion of it being an industry
initiative when in fact it isn't. Ironically all it WILL be is a
meaningless information schema. There is no guarantee a document will
exist that will ever tell you what to do with it, except by mining
expired drafts, which means it is not really a living technology. What
IANA would reference in allocating the code points is a good question.

3) If the WG actually requires demonstrated interoperability to get to
RFC, for the reasons outlined in 1 the rest of us likely will be held up
waiting for you to produce a competitor. And when there is no standards
track document defining WHAT to do with the TLVs, what constitutes
interoperability?

So WHY the IETF should grant you a fast track to broadening the
addressable market for your proprietary technology, allow OTV to gate
process for legitimate standards initiatives, and dignifying OTV as if
it was a product of the IETF completely escapes me. Why you should think
this draft is an appropriate vehicle to document a part of your
proprietary technology is either incredibly naieve or incredibly
disingenuous...

My 2 cents
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dhananjaya Rao (dhrao)
Sent: Tuesday, May 04, 2010 6:45 PM
To: [email-masked]
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Hi folks,

We're just catching up on the discussions on the mailing list regarding
the L2 IS-IS draft-ietf-isis-layer2-04.txt. As the authors of OTV, we'd
like to clarify any doubts or concerns regarding the extensions used by
OTV.

OTV shares along with TRILL/802.1aq several of the PDU/TLVs that have
been defined in this draft. There are of course a few additional
sub-TLVs defined specifically for OTV:

Thanks,

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

	          Pages           : 60

	          Date            : 2010-04-30

	This document 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 

	IS-IS extensions to explain how the information carried in IS-IS
is 

	used.

	implementation to automatically retrieve the ASCII version of
the 

	Internet-Draft.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 05 May 2010 15:34:44 -0700

> http://tools.ietf.org/html/draft-hasmit-otv-00.

I see there is an IPR disclosure for draft-hasmit-otv at
https://datatracker.ietf.org/ipr/1312/
and AFAICT it doesn't provide any licensing information.

That might be worth taking into consideration when the WG considers 
whether or not the OTV extensions belong in draft-ietf-isis-layer2-04.txt

    Erik

---

From: David Allan I <[email-masked]>
Date: Wed, 5 May 2010 18:55:29 -0400

Hi Victor:

This is not progress and innovation, this is simply bad behavior and as such should not be rewarded....

Please go away and publish something informational track and request your own IANA code points if you are now so genuinely concerned about the "common good", you obviously weren't when you started shipping....

D

________________________________
From: Victor Moreno (vimoreno) [mailto:[email-masked]]
Sent: Wednesday, May 05, 2010 5:46 PM
To: David Allan I
Cc: Venu Venugopal (venuv); Hasmit Grover (hasmit); Ben Basler (bbasler); Martina Beitat (mbeitat); Luyuan Fang (lufang); Dhananjaya Rao (dhrao); [email-masked]
Subject: RE: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Hi David,

The intent is to open the technology for broad implementation and with it the addressable market and vendor opportunity. In this vein, the goal is to avoid overlap in the future use of the TLV/codepoint space by having the ISIS WG's use of these TLVs formally documented, fully disclosed and (hopefully) acknowledged/agreed upon.

Rather than seeing an early implementation as a competitive threat, I would look at it as an opportunity to capitalize on the existing ramp-up investment/learning curve and reduce your time to market, costs and overall risk of a solution like OTV.

It is important that there is an authoritative registry of TLVs and codepoints so that conflicts are avoided. I think as a WG that can be achieved and it is far from useless information.

There is a draft submitted explaining what to do with these TLVs for OTV. If it is not satisfactory, it can be improved, but that is a task for a different WG. The request from the ISIS WG is simple: document the TLVs/codepoints formally and in a timely manner. In the same way as OTV leverages TLVs that were originally conceived for TRILL, there is potential for the additional TLVs to play in other solutions beyond OTV. So beyond this tactical argument, my opinion is that these TLVs could be strategically generalized and therefore belong in the WG.

We are coming to the WG because the TLVs will be used in a shipping implementation, they are being disclosed to the community and this information needs to be discussed and documented. Mine is but one opinion, it is ultimately up to the WG, but we are disclosing information that has an impact on future activities in the ISIS space. I would think the WG wants to do the right thing and accommodate for progress and innovation while maintaining control of the TLV and codepoint allocation landscape.

Regards,

-v

From: David Allan I <[email-masked]<mailto:[email-masked]>>
Date: May 5, 2010 4:58:47 AM PDT
To: "Dhananjaya Rao (dhrao)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Hi Dhananjaya:

My 2 cents
D

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dhananjaya Rao (dhrao)
Sent: Tuesday, May 04, 2010 6:45 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Hi folks,

Thanks,

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-isis-layer2-05.txt>
_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 06 May 2010 01:07:15 +0200

Hi David,

I think there is nothing wrong with shipping pre-standard 
implementations of any protocol.

Of course vendor takes a risk here if by going via standards process the 
spec will change based on the input from WG. Then he has to worry about 
interoperability issues with his pre-standard implementation.

Remember how tag switching surfaced ?

If you want to go this path I am sure you are very well aware that there 
is a really long list from any vendor to publish a draft when an 
implementation is ready.

I don't want to start any sort of flame war here on that. But I think 
this was never a showstopper in IETF to have an implementation. Of 
course authors can not use it as justification of any sort and here I am 
with you and others.

So considering both drafts on the table I think draft-hasmit-otv-00 is a 
very good individual contribution which does in fact has a lot of 
technical merit.

On the draft of draft-ietf-isis-layer2-05.txt I think the best way would 
be to indeed separate the new encoding into a separate draft, submit as 
individual contribution (there is still some time before next IETF in 
Maastricht and ask for agenda item on this or other WG to present.

Would you and other's agree that this could be the best way out from 
this thread ?

Cheers,
R.

> Hi Victor:
> This is not progress and innovation, this is simply */bad behavior/* and
> as such should not be rewarded....
> Please go away and publish something informational track and request
> your own IANA code points if you are now so genuinely concerned about
> the "common good", you obviously weren't when you started shipping....
> D

---

From: David Allan I <[email-masked]>
Date: Wed, 5 May 2010 19:41:24 -0400

Hi Robert: 

I think there is nothing wrong with shipping pre-standard implementations of any protocol.

DA> Wild agreement. There is something wrong with suggesting having shipped it makes it a done deal...

Of course vendor takes a risk here if by going via standards process the spec will change based on the input from WG. Then he has to worry about interoperability issues with his pre-standard implementation.

DA> Exactly, but as near as I can tell based on how this happened and the comments from the proponents of OTV, they are not interested assuming that risk. They simply want the code points. I have a problem with that, at least on standards track.

If you want to go this path I am sure you are very well aware that there is a really long list from any vendor to publish a draft when an implementation is ready.

DA> Sorry, not quite parsing that statement.

I don't want to start any sort of flame war here on that. But I think this was never a showstopper in IETF to have an implementation. Of course authors can not use it as justification of any sort and here I am with you and others.

DA> exactly, there are well understood ways in the IETF to be good citizens and still do proprietary things, and keep them that way for that matter...

So considering both drafts on the table I think draft-hasmit-otv-00 is a very good individual contribution which does in fact has a lot of technical merit.

DA> That's nice, but I don't necessarily see that as relevant to this discussion.

On the draft of draft-ietf-isis-layer2-05.txt I think the best way would be to indeed separate the new encoding into a separate draft, submit as individual contribution (there is still some time before next IETF in Maastricht and ask for agenda item on this or other WG to present.

DA> I presume you are referring to splitting out the OTV components. I of course believe they do not belong in draft-isis-layer-2, but before they are even considered by IS-IS WG in another form I actually think draft-hasmit needs a home, such that the IS-IS extensions are not simply a schema with no defined semantics in some enduring form (cf. simply some expired draft at some point in the future)...The mere existence of an individual submission is not justification for a WG to take on an item...

Would you and other's agree that this could be the best way out from this thread ?

DA> I think I've been clear, there is really two possibilities. One is OTV needs to be adopted as a standards track item, charter change yadda yadda (and this is more than just the IS-IS TLVs), to which L2VPN looks like the most appropriate home, otherwise it is BOF time. Once it is on track to produce a document both IS-IS WG and IANA can reference, it can progress from there. The other alternative is informational track. Those are the choices we all have when we choose to introduce technology to the IETF, it's up to the OTV proponents which path they take...

Anything else seems patently incomplete and a bad idea...or inappropriate...

Rgds
D

> Hi Victor:
> This is not progress and innovation, this is simply */bad behavior/* 
> and as such should not be rewarded....

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 06 May 2010 01:57:53 +0200

Hi David,

I think we are on the same wavelength in 98% of the mail. So I just try 
to point those little 2% which I would question ...

> DA>  I presume you are referring to splitting out the OTV components.

Yes.

> I of course believe they do not belong in draft-isis-layer-2,

Well I think they do belong nicely there. OTV is an L2 technology. So 
from new implementer and customer POV it is nice to have one doc to 
read, compare what makes most sense for them to deploy.

But yes .. new draft .. WG doc .. then merge path with the above.

> before they are even considered by IS-IS WG in another form I
> actually think draft-hasmit needs a home, such that the IS-IS
> extensions are not simply a schema with no defined semantics in some
> enduring form (cf. simply some expired draft at some point in the
> future)...The mere existence of an individual submission is not
> justification for a WG to take on an item...
 >
> DA>  I think I've been clear, there is really two possibilities. One
> is OTV needs to be adopted as a standards track item, charter change
> yadda yadda (and this is more than just the IS-IS TLVs), to which
> L2VPN looks like the most appropriate home, otherwise it is BOF time.
> Once it is on track to produce a document both IS-IS WG and IANA can
> reference, it can progress from there. The other alternative is
> informational track. Those are the choices we all have when we choose
> to introduce technology to the IETF, it's up to the OTV proponents
> which path they take...

Well .. charter change seems to me always like a heading to brick wall 
so I am not sure if that is needed in L2VPN. But informational track is 
just fine too. Nothing wrong with that. Some technologies did in fact 
very well while starting informational :) /* As you very well know I am 
sure */

> Anything else seems patently incomplete and a bad idea...or

I think we have that one covered so time to move on to new challenges :)))

Many thx,
R.

---

From: David Allan I <[email-masked]>
Date: Wed, 5 May 2010 20:07:56 -0400

DA2> OK, the 2%

I think we are on the same wavelength in 98% of the mail. So I just try to point those little 2% which I would question ...

Yes.

> I of course believe they do not belong in draft-isis-layer-2,

Well I think they do belong nicely there. OTV is an L2 technology. So from new implementer and customer POV it is nice to have one doc to read, compare what makes most sense for them to deploy.

DA2> OTHER ISSUES ASIDE, it is has been clearly demonstrated that the 3 technologies in the draft all have complely orthogonal sets of TLVs. There is no reason to keep them together.

DA2> If someone can show me a document that describes how OTV works is on RFC standards track, I'll agree references to it belong in a standards track RFC that documents the routing schema for it. As long as it is proprietary, it should be treated as such, and have the common decency to stay out of the way....

> before they are even considered by IS-IS WG in another form I actually 
> think draft-hasmit needs a home, such that the IS-IS extensions are 
> not simply a schema with no defined semantics in some enduring form 
> (cf. simply some expired draft at some point in the future)...The mere 
> existence of an individual submission is not justification for a WG to 
> take on an item...
 >

Well .. charter change seems to me always like a heading to brick wall so I am not sure if that is needed in L2VPN. But informational track is just fine too. Nothing wrong with that. Some technologies did in fact very well while starting informational :) /* As you very well know I am sure */

DA2> Yep

DA2> Would like to think so, I would have thought this was much more cut and dried, more fool me...

D

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 5 May 2010 22:52:44 -0700

Donald -

> Behalf Of Donald Eastlake
> Sent: Wednesday, May 05, 2010 6:29 AM
> To: Ralph Droms
> Cc: [email-masked]
> The existing table in draft-ietf-isis-layer2-05 in Section 5, split
> across pages 56 and 57, has an "LSP" column and an "MGROUP LSP"
column.
> By implication, those protocols indicated in the TRILL/IEEE/OTV column
> for an TLV/sub-TLV with an X in the MGROUP LSP column are specified in
> that draft as using the MGROUP set of PDUs. However, I, along with
many
> others, think the MGROUP cluster of three PDUs is unnecessary and
> should just be eliminated from the draft.
> 
> never use the "LAN Hello" used at Layer 3 and non-TRILL
implementations
> of IS-IS never issue a TRILL Hello. (Both use the same P2P Hello on
P2P
> links.) Since TRILL and Layer 3 frames are distinguished by using
> different multicast addresses and by using Area Addresses which are in
> practice, if not in theory, completely disjoint. Thus there are
already
> 2 means of separating "LAN Hellos" frames from "TRILL Hellos" and, as
I
> say, using a different PDU number for TRILL Hellos was suggested only
> out of an abundance of caution.

If such caution is needed for LAN IIHs, why is it not also needed for
P2P Hellos, LSPs, CSNPs, and PSNPs?

The answer that because there is new TLV information in TRILL Hellos
seems inadequate as there is clearly also new TLV information in LSPs
when used for L2.

I would also point out that in
http://tools.ietf.org/id/draft-ietf-isis-mi-02.txt wherein multiple
instances of Layer 3 would be operating on the same link, no new PDUs
are specified. 

The presence of different multicast destination addresses seems quite
robust. If it is known that both L2 and L3 are operating on the same
link different system IDs can be used for the two instances. This
provides additional protection in the case that a neighboring legacy L3
instance mistakenly processes L2 PDUs. Since the L2 instance will not
form an adjacency w the L3 instance, no two way connectivity will ever
be achieved.

I see no need for a new PDU for "TRILL Hellos".

   Les

> 
> The MTU-probe and MTU-ack provide a simple one-hop request-response
way
> to test link MTU. Implementation of MTU-probe is optional but a TRILL
> implementation receiving an MTU-prove must respond with an MTU-ack.
MTU
> is a loop safety consideration for TRILL. This MTU facility, and the
> ability to report MTUs with the extended IS reachability MTU sub-TLV,
> could also be used, for example, by Layer-3 IS-IS to collect
> information on which to base traffic engineered routes meeting some
> minimum MTU requirement.
> 
> Thanks,
> Donald
> 
> 	John - I understand that OTV is a proprietary protocol.  My
> questino was asked to find out about applicability of those PDUs -
> which protocols require which PDUs, and what is the motivation for
> including each of those PDUs in draft-ietf-isis-layer2-05.txt.
> 
> 	- Ralph
> 
> 
> 		I think the point is that unlike TRILL, and IEEE
802.1aq,
> OTV is proprietary - nobody other than its designers has any idea how
> it works.
> 
> 			Subject: Re: [Isis-wg] I-D
Action:draft-ietf-isis-
> layer2-05.txt
> 
> 			Which of TRILL, IEEE 802.1ag and OTV use each of
the
> PDUs defined in
> 			draft-ietf-isis-layer2-05.txt?  Is it possible
to
> devise an
> 			applicability or usage table, similar to the
table
> for TLVs in section

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 06 May 2010 00:22:55 -0700

> Maastricht and ask for agenda item on this or other WG to present.

I think it would be a good idea to separate out the OTV material from 
draft-ietf-isis-layer2.

But instead of presenting OTV in different WGs looking for a home I 
would recommend the normal IETF procedure for when somebody wants to 
work on a new protocol like OTV; ask the ADs to sponsor a BoF on OTV.

If I don't misremember that was how the proprietary tag switching turned 
into the IETF MPLS standardization work.

    Erik

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Thu, 6 May 2010 08:49:02 -0500

Hi Robert 

You wrote :
 
"On the draft of draft-ietf-isis-layer2-05.txt I think the best way would be to indeed separate the new encoding into a separate draft, submit as individual contribution (there is still some time before next IETF in Maastricht and ask for agenda item on this or other WG to present.

Would you and other's agree that this could be the best way out from this thread ?"

On this I agree, 
Don 

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Robert Raszuk

Hi David,

Cheers,
R.

<snip>

---

From: David Allan I <[email-masked]>
Date: Thu, 6 May 2010 10:16:14 -0400

I get the feeling consensus is emerging...

1) draft-ietf-isis-layer-2 is reissued with OTV removed. 
2) OTV folks make their choice (existing WG, BOF, informational) as to how they progress their technology...

This looks good to me
D  

-----Original Message-----
From: Fedyk, Donald (Don) [mailto:[email-masked]] 
Sent: Thursday, May 06, 2010 9:49 AM
To: [email-masked]; [email-masked]; David Allan I
Subject: RE: [Isis-wg] I-D Action:draft-ietf-isis-layer2-05.txt

Hi Robert 

You wrote :

On this I agree,
Don 

-----Original Message-----

Hi David,

Cheers,
R.

<snip>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 6 May 2010 17:19:51 -0400

Hi Les,

Thanks for this comment. I agree with your arguments and believe that
there is insufficient reason for a separate PDU number for TRILL
Hellos. TRILL Hellos should just use the LAN IIH PDU number.

Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA