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

From: Christian Franke <[email-masked]>
Date: Fri, 03 Jul 2015 20:50:41 +0200

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

---

From: Karsten Thomann <[email-masked]>
Date: Sun, 05 Jul 2015 20:37:49 +0000

Hi Christian,

some comments from my side:
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

In my opinion you should also add to the IANA Considereations section that the allocation of the 
protocol number should be modified to something like "ISIS over IP" or only "ISIS", as it is a bit 
misleading that it's currently "ISIS over IPv4"

Also there should be at least some information about the coexistence of "standard" ISIS Routers 
and "ISIS over IPv6" routers. Example would be to allow only one ISIS encapsulation per interface 
and ignore the other (Router running ISIS over IPv6 with adjacencies would ignore standard ISIS 
PDUs and vice versa)
If you're not specifying it there arise problems with DIS routers.

Nit:
/of transmitted the PDUs/of transmitted PDUs/

Regards
Karsten Thomann

---

From: Christian Franke <[email-masked]>
Date: Mon, 06 Jul 2015 21:04:02 +0200

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

> should at least mention that it avoids some problems with switches dropping ISIS LSPs if it's 

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?

-Christian

---

From: prz <[email-masked]>
Date: Mon, 06 Jul 2015 14:09:55 -0700

> in that way. Could you name examples for switches showing this 

 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

---

From: Karsten Thomann <[email-masked]>
Date: Thu, 09 Jul 2015 21:33:25 +0000

Hello Christian,

an example of a switch dropping ISIS packets is a GS2200 from Zyxel, it is even mentioned in the 
release notes of the (older) firmware.
ftp://ftp2.zyxel.com/GS2200-24P/firmware/GS2200-24P_400BPN3C0.zip
In the pdf document page 12, fixed bug number 4.

Some additional comments:
3.1 SNPA
I would use the link local IP as a tie breaker, as on the subnet are only routers able to establish 
adjacencies if they are capable of ISIS over IPv6 and there is no backwards compatibillity needed 
in this case.

PPP for example makes sure there are unique Interface identifiers within the IPV6CP negotiation 
and Ethernet with DAD, protecting users against their own misconfiguration would be (almost) 
impossible.

3.2 MTU
Why you're restricting the packet size to 1280bytes?
The ISIS Packets SHOULD be padded up to the maximum mtu size to detect mtu mismatches on 
the links. It is right not to use fragmentation, but this shouldn't require to limit the size to 1280 
bytes.
Maybe add to the fragmentation related sentence that all fragmented ISIS packets MUST be 
ignored/dropped.

Regards
Karsten

Am Montag, 6. Juli 2015, 21:04:02 schrieb Christian Franke:
> > 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
>

---

From: Christian Franke <[email-masked]>
Date: Thu, 09 Jul 2015 22:30:47 +0200

> an example of a switch dropping ISIS packets is a GS2200 from Zyxel, it is even mentioned in the 

Thank you for the info.

> adjacencies if they are capable of ISIS over IPv6 and there is no backwards compatibillity needed 

That sounds sensible, I think I will use this approach.

> Maybe add to the fragmentation related sentence that all fragmented ISIS packets MUST be 

The MTU part indeed is still a bit of an issue as it is currently in the
draft.

The intention of the limit to 1280 is to allow it to work exactly the
same over various links, as all IPv6 capable links have to support an
IPv6 MTU of 1280.

However if this is used, one would need another mechanism than padding
to verify that MTUs of all routers on one link match - not sure if that
design (which is already used by OSPF) would be appreciated by this
working group as I think that the robustness that the padding adds -
e.g. allowing to detect brigeds with too small mtu in between of the
routers - is a valued feature of IS-IS.

One feature that this would allow though is indeed using fragmentation
which would permit to transport standard LSPs over IPv6 which may
otherwise be too large. However it might be cleaner to state that people
need to live with a smaller LSP size if they use IS-IS over IPv6 and
just forbid fragmentation.

Would be glad to hear your opionion on how you weight these aspects.

-Christian

---

From: Karsten Thomann <[email-masked]>
Date: Sun, 12 Jul 2015 12:40:04 +0000

Am Donnerstag, 9. Juli 2015, 22:30:47 schrieb Christian Franke:
> > I would use the link local IP as a tie breaker, as on the subnet are only
> > routers able to establish adjacencies if they are capable of ISIS over
> > IPv6 and there is no backwards compatibillity needed in this case.
> 
> > The ISIS Packets SHOULD be padded up to the maximum mtu size to detect mtu
> > mismatches on the links. It is right not to use fragmentation, but this
> > shouldn't require to limit the size to 1280 bytes.
> > Maybe add to the fragmentation related sentence that all fragmented ISIS
> > packets MUST be ignored/dropped.
> 
ISIS would run exactly the same regardless of the MTU.
> to verify that MTUs of all routers on one link match - 
Why would we need another mechanism?

> not sure if that
The hello padding is a "shall" requirement in the ISIS specification...

> otherwise be too large. 
I don't understand this, as ISIS has an internal mechanism to handle LSPs which are bigger than 
the MTU of the interface.
If e.g. CSNP is too large for the link MTU it is splittet and the covered range of LSPs is mentioned 
in the Start LSP ID to End LSP ID.

And for LSPs the router has to generate a multipart LSP.

I wouldn't want to change this internal fragmentation mechanism.

> However it might be cleaner to state that people
Wouldn't do it as already explained above.
> Would be glad to hear your opionion on how you weight these aspects.

To summarize this:
- keep the ISIS internal mechanism to handle (C/P)SNP and LSP fragmentation
- allow the maximum possible MTU of the link for packets
- hellos are padded everytime to maximum possible size
- forbid fragmented ISIS IPv6 packets and log them (as there is something really weird if you 
receive them)

I'm a bit curious how the two opensource implementations currently handling this cases.

Karsten

---

From: Christian Franke <[email-masked]>
Date: Sat, 18 Jul 2015 11:45:12 +0200

> I wouldn't want to change this internal fragmentation mechanism.

IS-IS fragmentation only works at the point of origination. If you have
IS-IS routers A,B,C like this, with the numbers indicating the links' MTUs:

+-----+ 1500 +-----+ 1280 +-----+
|  A  |------|  B  |------|  C  |
+-----+      +-----+      +-----+

Router A may e.g. generate an LSP fragment 1400 bytes in size. To my
knowledge, there is no mechanism in IS-IS to allow for router B to
transmit this fragment to router C.
The solution for this case is to configure all routers to generate only
LSP fragments <= 1280 bytes in size.

One consideration was to fix the LSP for IPv6 mode to generate only
packets <= 1280 bytes, since any IPv6 link has to be able to transport
1280byte IPv6 packets. Then again, limiting the size to <=1280 bytes is
something that is not strictly needed, so it might best be made only a
recommendation.

Using 1280bytes for hellos was indeed an unreasonable idea on my side
and should be changed.

> Wouldn't do it as already explained above.

Forbidding fragmentation was meant to refer to IP level fragmentation.
If IP level fragmentation is not allowed, people will have to set a
smaller LSP size as e.g. a maximum LSP Fragment transportable via
Ethernet with 1500 - sizeof(LLC-Header) is greater than 1500 -
sizeof(IPv6-Header).

> - forbid fragmented ISIS IPv6 packets and log them (as there is something really weird if you 

I think we a in agreement there. I would go for this:

- IS-IS over IPv6 packets SHALL NOT use IPv6 fragmentation
- Hello packets SHOULD be padded so the resulting IPv6 packets reaches
  the maximum L3 MTU
- recommend that LSPs are only generated so that the IPv6 IS-IS packets
  are <= 1280 bytes in size, but allow for larger packets at the
  operator's discretion

> I'm a bit curious how the two opensource implementations currently handling this cases.

The opensource implementations are currently still at a prototype state
and therefore don't have strong error handling yet. LSP size is set so
that it will fit into 1280bytes, there is however no check done to
verify that received packets are not fragmented.

(By the way, I am not sure if standard socket API provides a way to
figure out whether a received packet was fragmented, but somehow it
should probably be doable.)

-Christian

---

From: Karsten Thomann <[email-masked]>
Date: Sat, 18 Jul 2015 14:30:29 +0000

Am Samstag, 18. Juli 2015, 11:45:12 schrieb Christian Franke:
> > I don't understand this, as ISIS has an internal mechanism to handle LSPs
> > which are bigger than the MTU of the interface.
> > If e.g. CSNP is too large for the link MTU it is splittet and the covered
> > range of LSPs is mentioned in the Start LSP ID to End LSP ID.
> > 
You're right.
I was still thinking between Routers A and B, as the problem with the MTU is not unique to IPv6 
transport.
> something that is not strictly needed, so it might best be made only a
Agree that recommendation seems to be the best, as it is a working default for all IPv6 links.
> Ethernet with 1500 - sizeof(LLC-Header) is greater than 1500 -
That is in my opinion the only way to handle it.

We have still the problem that non IPv6 based areas can have LSP sizes which can exceed the 
suported limit with IPv6 based transport with a standard Ethernet MTU of 1500.

I have no idea how we want to avoid proper network planning and setting of lsp sizes on all 
devices.
Operators which use ISIS over e.g. Ethernet and want to add IPv6 based transport for ISIS on 
some links must simply be aware about the lsp size limits.

Regards
Karsten
> > - forbid fragmented ISIS IPv6 packets and log them (as there is something
> > really weird if you receive them)
>