Subject: Re: [Isis-wg] Fwd: New Version Notification for draft-franke-isis-over-ipv6-00.txt

From: Marc Binderberger <[email-masked]>
Date: Sun, 22 Nov 2015 17:30:50 -0800

Hello Tony,

one question about the IPv4 draft "draft-ietf-isis-wg-over-ip": what happened 
to it?  Why was the work stopped?

It got to workgroup level, so must have passed some checks and tough 
questions :-) - and then R.I.P ?

Regards, Marc

On Mon, 06 Jul 2015 14:09:55 -0700, prz wrote:
> On Mon, 06 Jul 2015 21:04:02 +0200, Christian Franke 
> <[email-masked]> wrote:
>> Hello Karsten,
>> 
>> thank you for your input. I have made appropriate changes to the draft,
>> they can be seen here:
>> 
>> https://git.netdef.org/projects/OSR/repos/drafts/commits/8a6e90598a4ce
>> 
>> On 07/05/2015 10:37 PM, Karsten Thomann wrote:
>>> I'm not sure if we really need this encapsulation, as there are not many 
>>> links layers left, but you
>>> should at least mention that it avoids some problems with switches 
>>> dropping ISIS LSPs if it's
>>> encapsulated in IPv6
>> 
>> The homenet working group is currently in the process of selecting a
>> routing protocol to use. In that discussion some people voiced concern
>> that IS-IS would not be a good option since it was specified on top of
>> layer 2 instead of layer 3. This draft and the demo implementation were
>> done to address these concerns. On the one hand by showing that it
>> doesn't take much to run IS-IS on top of layer 3 and on the other hand
>> to provide a standardized way to do so, should the need arise.
>> 
>> I was not aware that switches existed which drop IS-IS PDUs, although
>> it's not that hard to imagine that there are switches which are broken
>> in that way. Could you name examples for switches showing this behavior?
>> 
> 
> Hey Christian, looked @ it with one eye & since the SNAP size problem for 
> ipv6 looks rather ugly to me, a question would be whether you considered 
> use of RFC3927 to resolve the 'no ipv4 on interface' problem and just use 
> the original draft for isis over v4 (in case when no ipv4 is assigned on 
> interface, otherwise the '99 draft would work fine out-the-box). RFC3927 
> should take care of the 'same subnet' check as well that as far I remember 
> is in all major implementations (since it's all on same /16).
> 
> Just random musing given that all the solutions suggested for the ipv6 in 
> SNAP in the draft look a tad of a round peg in a square hole to me ;-)
> 
> Yes, I know HomeNet is all about IPv6.
> 
> -- tony
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: prz <[email-masked]>
Date: Sun, 22 Nov 2015 18:11:17 -0800

> questions :-) - and then R.I.P ?

 The major driver was then (we're talking about Internet Bronze Age ;-)
 I think MCI wanting to play with ISIS without all the SNAP stuff to get
 data onto some PCs. They
 were using early Linux or FreeBSD and the SNAP was a problem.

 We had an implementation for them AFAIR but then Cisco did not support
 the work with the beating 'security through obscurity with ISO' 
 argument that
 "someone could send packet with dst address of your router from 
 'outside
 your domain'".

 Now, don't forget, this was routing area IETF where 'you don't have
 2 major vendor inter'oping in field with real implementation means
 you can't WG LC'  (as it should be IMO). So we had de-facto some Fore
 implementation, CSCO wasn't on it, people like Bay were all in
 corporate where ISIS wasn't used, smaller players didn't have ISIS,
 people changed jobs ;-)
 So, it all got shelved.

 Couple of years down the road all major vendors had proper LLC/SNAP
 support in their kernels/stacks and the issue was not much of an issue
 anymore ...

 To be fair, Tony & Dino (AFAIR again) wrote GRE down (2784) and that
 got very good traction until today and with that the issue was kind of
 moot for major vendors since e'one had to implement GRE and with that
 you could encaps ISIS to anywhere. Irony being of course that people
 started to talk about 'auto-termination of GRE tunnels' and with that
 allow the 'attacks into the middle of network' ;-)

 This is all reconstructing from memory after 20 years so I may have
 gotten some stuff factually wrong, other oldtimers may correct me.

 Having said all that, I still think that ISIS-o-ip4 makes sense for
 its simplicity, my concerns about the ip6 attempts described in the 
 draft
 I already kind of sketched out albeit HomeNet is all about IPv6 
 obviously ...

 Speaking of which, maybe running one-hop auto-GRE tunnel (or some other
 little tunneling monstrosity ;-) & putting ISIS over
 it would be an option for HomeNet (don't think I ever saw that done). 
 Just
 a random thought ...

 -- tony

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 23 Nov 2015 00:09:35 -0500

Hi,

In order to be able to treat an IP network as a link type between
TRILL routers, TRILL needs to be able to send TRILL IS-IS packets
between TRILL routers in a manner that does not interact with use of
IS-IS within the IP network. So I've thought a fair amount about IS-IS
over IP. There has been a TRILL WG draft on this for some time.

I think you are right that the correct thing for IPv6 is to use the
port's IPv6 address as the SNPA.

Your isis-over-ipv6 draft says that SNPAs don't occur on the wire,
just within IS-IS routers. But I believe they occur in IS-IS Hellos.
See TLV #6, referred to as "IIS Neighbors" in IANA's TLV table and
shown in ISO/IEC 10589-2002 Second Edition in Clause 9.5, item "a",
page 68. I just checked and that IS-IS TLV is specified as being
limited to 48-bit SNPAs. Looking further, the ISO/IEC standard seems
to have a TLV #7, shown in item "b" on that page for specifying
neighbor SNPAs and that TLV #7 does have an SNPA length field so they
could be some other length. Maybe I'm confused, but, it appears that
the IETF has re-assigned TLV #7 to be Instance Identifier (RFC6822).
Since you say there are interoperable implementations of your draft,
am I confused or do they have some solution to the above problem?
Perhaps, since Hellos are link local, the implementations just use
fixed size 128-bit SNPAs in their IIS Neighbors TLVs over IPv6,
contrary to the ISO specification, and this was left out of the draft?

(This is not a problem for TRILL over IP as TRILL uses the TRILL
Neighbor TLV (#145, RFC 7176) which does provide an SNPA length
field.)

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

On Fri, Jul 3, 2015 at 2:50 PM, Christian Franke
<[email-masked]> wrote:
> Dear all,
>
> In this new draft, I'd like to propose an alternative method to transmit
> IS-IS PDUs. By using IPv6 as transport, it makes the protocol less
> dependent on specific link-layers.
>
> There are two interoperable free software implementations for this which
> will be published until the IETF in Prague and which will be presented
> there during Bits-N-Bites.
>
> I'd be happy to receive your feedback.
>
> -Christian
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-franke-isis-over-ipv6-00.txt
> Date: Fri, 03 Jul 2015 11:27:10 -0700
> From: [email-masked]
> To: Christian Franke <[email-masked]>, Christian Franke
> <[email-masked]>
>
>
> A new version of I-D, draft-franke-isis-over-ipv6-00.txt
> has been successfully submitted by Christian Franke and posted to the
> IETF repository.
>
> Name:           draft-franke-isis-over-ipv6
> Revision:       00
> Title:          IS-IS over IPv6
> Document date:  2015-07-03
> Group:          Individual Submission
> Pages:          5
> URL:
> https://www.ietf.org/internet-drafts/draft-franke-isis-over-ipv6-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-franke-isis-over-ipv6/
> Htmlized:       https://tools.ietf.org/html/draft-franke-isis-over-ipv6-00
>
>
> Abstract:
>    In this draft, a method to transmit IS-IS PDUs as IPv6 packets is
>    described.  While the default encapsulation of IS-IS is specified
>    directly on top of the link-layer, making it necessary for IS-IS to
>    be specified for each link-layer it should be used on, the proposed
>    method allows for IS-IS to run on any link-layers supporting IPv6.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
>