Subject: Re: [homenet] some IS-IS questions

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Jul 2015 22:35:58 +0000

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Monday, July 27, 2015 4:50 PM
To: [email-masked]
Subject: [homenet] some IS-IS questions

>Given some of the discussion last week, I found that I had some questions about what is or isn't already defined somewhere within the set of IS-IS specs *and* is already implemented in a load suitable >for a homenet router. I've read the Babel specs, so I have a good idea of what's in Babel. Plus there was that really good Babel presentation Thursday night. But I'm having real trouble finding the right IS->IS specs to answer my questions.

>There was a claim that IS-IS provides "diagnostics". 
>What sort of diagnostics? 

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r43/routing/configuration/guide/b_routing_cg43xasr9k/b_routing_cg43xasr9k_chapter_01011.html#concept_B475330101904631B14C625066A033C3

Search at the above URL for " Route Convergence Monitoring and Diagnostics".

>Is this a reference to topology discovery? Does topology discovery rely on device participation in IS-IS, or can devices that do not participate in IS-IS be discovered? 

All devices in the IS-IS domain need to be routers.   Neighboring routers find each other by exchanging Hellos using multicast.   Loosely speaking, an IS-IS router uses link-state packet (LSP) to flood learnt prefixes and topology to neighbors.  IS-IS supports both IPv4 and IPv6 easily. 

>Can bridged devices be discovered?

Yes/No.  The bridge would need to be a RBridge such as in TRILL and then the bridge can be discovered.   Or if the bridge is connected to an IS-IS router or a switch connected to the IS-IS router, the router/switch can learn the end bridged device mac-address.  The learnt mac-address can be propagated to IS-IS using  a sub TLV in IS-IS.

> If yes, can they be discovered even if they don't do IS-IS? If yes, how does that work?

See above. 

>Can physical layer topology be discovered?

IS-IS knows who its neighbors are and also knows the path to any other neighbor.   Wouldn't this suffice?  Or please give an example of a physical layer topology that the network layer is not able to provide.

>What additional diagnostics outside of topology discovery does IS-IS support?

See the URL I mentioned above.

>I was told that IS-IS can help avoid loops caused by bridged interfaces as well as routed interfaces? Is this correct? 

Not quite.  When IS-IS was added to RBridges by TRILL, it is the TRILL header that includes a Hop count that helps avoid routing loops, not IS-IS.   IS-IS is a connection-less protocols and thus a TTL (or hop count) in the IPv4 header cannot be leveraged to avoid loops.  IS-IS avoid loops as soon as the new network topology is flooded to all the routers within the routing area.

>If yes, does it rely on participation of bridges in IS-IS, or can it be done with only participation by routers?

See above.

>I was told that with IS-IS a "service provider" router could somehow automatically take control of QoS and routing policy in the network, and dictate policy to other routers (assuming the other routers >even have a QoS policy). Is this true? How does this work, especially if there are multiple "service provider" routers? Would this be in the IS-IS version suitable for homenet?

The home router does not include the WAN interface in LAN routing whether the routing is IS-IS or another routing protocol.   Then IS-IS only operates in the home LAN.  I defer to others to signaling QoS with IS-IS or taking over routing policy.  IS-IS is flexible and adds new functionality in a jiffy using TLV option and sub-TLV options.   

>I was told that if IS-IS is selected, hosts will be able to do resource reservation across the homenet. Resource reservation has yet to be implemented in unmanaged home network devices, though many >standards have been written. In general, the complexity of supporting resource reservation schemes has never been worth the cost. Is this something that will suddenly work as a result of IS-IS >implementation in routers? Is it in the IS-IS subset proposed for homenet? What does it require in the hosts?

IS-IS has no implication on hosts.  Resource reservation using RSVP is performed for QoS in the Internet.  IS-IS runs in the LAN.

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 28 Jul 2015 14:24:22 +0000

Hi Hemant,
Thanks for the reply, but...

> http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4
> 3/routing/configuration/guide/b_routing_cg43xasr9k/b_routing_cg43xasr9k
> _chapter_01011.html#concept_B475330101904631B14C625066A033C3
> 

The link didn't work for me (and, yes, I made sure the entire string was there), but I searched on the Cisco site for ASR 9000 documentation and found instructions for configuring/enabling this Cisco function, and a  statement that such a function exists. I still have no clue what this function does -- what the detailed output is, and how to interpret. Some people say they want IS-IS because it can also do some sort of diagnostics, but I still have no idea what these diagnostics are. BTW, I did do a quick price scan of Cisco ASR 9000 series routers, and believe they may be just a little bit outside the range of the average consumer. So I don't know if it would be reasonable to find this RCMD functionality in a consumer-grade router.

> >Is this a reference to topology discovery? Does topology discovery rely on
> device participation in IS-IS, or can devices that do not participate in IS-IS be
> discovered?
> 
> All devices in the IS-IS domain need to be routers.   Neighboring routers find
> each other by exchanging Hellos using multicast.   Loosely speaking, an IS-IS
> router uses link-state packet (LSP) to flood learnt prefixes and topology to
> neighbors.  IS-IS supports both IPv4 and IPv6 easily.

So when IS-IS talks about topology discovery, it's talking about router topology, with no knowledge of hosts or bridges or PHY technologies. I'm sorry, but in a home network, the router topology is really the least of my worries.

> Yes/No.  The bridge would need to be a RBridge such as in TRILL and then the
> bridge can be discovered.   Or if the bridge is connected to an IS-IS router or a
> switch connected to the IS-IS router, the router/switch can learn the end
> bridged device mac-address.  The learnt mac-address can be propagated to
> IS-IS using  a sub TLV in IS-IS.

So the answer is no. Bridges are not going to be discovered in a homenet IS-IS topology.

> IS-IS knows who its neighbors are and also knows the path to any other
> neighbor.   Wouldn't this suffice?  Or please give an example of a physical
> layer topology that the network layer is not able to provide.

No, this does not suffice. I'll have to spend some time putting together my physical layer examples. In short, the vast majority of problems in the home network are due to issues of physical connectivity -- links go up and down causing consumer electronics devices to "lose" their IP address(es) and stop working until something kicks the device's network interface to get an IP address again (with reboot being the easiest and most-likely-to-work form of kicking).

In short, I'm slowly coming to the following conclusions:
1. Whatever diagnostics / topology discovery mechanisms may exists in IS-IS are insufficient to be of any real use. So any argument for IS-IS based on the existence of such diagnostics is irrelevant. [But I can be swayed from this conclusion if someone can provide real info showing this conclusion is wrong -- in an IS-IS load suitable for homenet routers.]
2. Technologies that are not resilient against links that go up and down frequently and for no apparent reason are useless in a home network. These links are prevalent in the home network. And not just the wireless links. The powerline and even coax links are also subject to this problem. In my experience, these up-and-down links are The Number One Cause of home networking issues today.

Barbara

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Jul 2015 14:45:09 +0000

Barbara,

Humble apologies for the URL to the Cisco ISIS diags document.  Please use the tinyurl below which works.   I will read rest of your email later in the day and other emails from homenet as well. 

http://tinyurl.com/o8znoam

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2015 10:24 AM
To: Hemant Singh (shemant); [email-masked]
Subject: RE: some IS-IS questions

Hi Hemant,

> device participation in IS-IS, or can devices that do not participate 
> in IS-IS be discovered?
> 
> router uses link-state packet (LSP) to flood learnt prefixes and 
> topology to neighbors.  IS-IS supports both IPv4 and IPv6 easily.

> switch connected to the IS-IS router, the router/switch can learn the 
> end bridged device mac-address.  The learnt mac-address can be 
> propagated to IS-IS using  a sub TLV in IS-IS.

In short, I'm slowly coming to the following conclusions:
1. Whatever diagnostics / topology discovery mechanisms may exists in IS-IS are insufficient to be of any real use. So any argument for IS-IS based on the existence of such diagnostics is irrelevant. [But I can be swayed from this conclusion if someone can provide real info showing this conclusion is wrong -- in an IS-IS load suitable for homenet routers.] 2. Technologies that are not resilient against links that go up and down frequently and for no apparent reason are useless in a home network. These links are prevalent in the home network. And not just the wireless links. The powerline and even coax links are also subject to this problem. In my experience, these up-and-down links are The Number One Cause of home networking issues today.

Barbara

---

From: Steven Barth <[email-masked]>
Date: Tue, 28 Jul 2015 17:07:56 +0200

> So when IS-IS talks about topology discovery, it's talking about router topology, with no knowledge of hosts or bridges or PHY technologies. I'm sorry, but in a home network, the router topology is…
Maybe to add some info from the HNCP front: HNCP also maintains a topology graph,
so you will have a router topology independent of IS-IS in any case. Depending on how feature-rich your
individual routers are (e.g. if at least one of your HNCP routers on a link runs an MDNS-proxy), you can
enumerate all MDNS-capable devices on such links with the usual tools such as bonjour / avahi.

Beyond that you would need to run special (custom) services on each link, to e.g. let you query
DHCP leases and/or NDP/ARP information from a router on each link but that is probably even less specified.

However as for really transparent and unmanged switches or bridges you usually found in homes and that
therefore do not announce themselves in any way you are probably out of luck in detecting them.

> 2. Technologies that are not resilient against links that go up and down frequently and for no apparent reason are useless in a home network. These links are prevalent in the home network. And not…

I agree here, the problem is usually, you would need stuff like ethernet carrier detection to actively detect issues
but that is more often than not masked by some (internal) switch or NIC somewhere in the path.

Beyond that its a timer / packet loss thing, eventually any routing protocol will detect a longer lasting link
failure and reorganize. Mesh routing protocols should usually have an advantage here since intermittent
failure or lossy links is stuff they are explicitly designed for and so most of them can explicitly or implicitly
(e.g. through dynamic metrics / link costs) provide feedback about quality of certain links.

Then again this is all between individual routers. If you have a "funny" link with transparent cross-medium bridges
e.g. router ---ethernet--- switch ---powerline--- bridged-AP --wifi-- router and all is essentially one L2-domain
and then some clients somewhere in the mix, it will be problematic in any case.

Cheers,

Steven

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2015 11:55:16 -0400

> 2. Technologies that are not resilient against links that go up and down frequently and for no apparent reason are useless in a home network. These links are prevalent in the home network. And not…

It’s worth expanding on this a tiny bit, because I think it may not be entirely clear to folks who are working in the back office side of the router business.

Home users are not IETF people.   What IETF people do to get their home networks working is literally impossible for regular users, not because they are stupid but because they are not networking experts, or even literate about how IP networks function.  To them, a home network device is analogous to other objects they’ve seen in the world, like plumbing manifolds: http://www.houseneeds.com/plumbing-supplies/plumbing-pex-tubing-tools-accessories/viega-manabloc-manifold-3-8-inch-pex-total-ports-18-8-hot-10-cold-36182?gclid=CjwKEAjw0NytBRD-1d3QsdHNpR0SJACGXqgRCeb2_ATreIdw0FGjWiUxIpMKHWVoj-nGi5wxjYdIqBoC1SDw_wcB <http://www.houseneeds.com/plumbing-supplies/plumbing-pex-tubing-tools-accessories/viega-manabloc-manifold-3-8-inch-pex-total-ports-18-8-hot-10-cold-36182?gclid=CjwKEAjw0NytBRD-1d3QsdHNpR0SJACGXqgRCeb2_ATreIdw0FGjWiUxIpMKHWVoj-nGi5wxjYdIqBoC1SDw_wcB>

When a typical homenet user plugs home network routers together, abstract reasoning about how routing works _cannot_ be assumed, and even an understanding of what a WAN is and what a LAN is is really asking too much.   The goal of homenet is essentially to turn a home router into something that can be operated by someone who thinks of it as if it were a plumbing manifold with a power switch that works to reset it when the water (bits) isn’t flowing.

This means that the end user can be assumed to plug home routers together in arbitrary topologies, and to happily make topology changes whenever they need to plug something new in.   They can be assumed to think that wired and wireless networks are exactly equivalent, and therefore attempt to use wireless networks for transit without understanding the implications of doing so.

The interesting thing here is that for the most part IPv4 routers that do network address translation can be treated as if they are equivalent to plumbing manifolds, and things mostly work.   It’s not perfect, but it’s a good baseline for comparison.

Our goal is for this to work in a multihomed IPv6 environment.   To work well, not just to limp along.   The network should recover as quickly from topology events such as I’ve described as a current home network with a single router recovers from power cycling the router, if not more quickly.

So when we are making decisions about routing protocols, and people are advancing routing protocols that they think should work well in the homenet, this is the base assumption that they should be using for evaluating the routing protocol.   If you do not already know of a way to make your favorite routing protocol combined with HNCP do what I have described here _automatically_, then your routing protocol is not feature-equivalent to Babel, and would need enhancement in order to be an equal replacement for Babel.

And if you, like many home users, think that wireless and wired networks are equivalent, or can’t clearly enumerate the various ways in which wired and wireless networks differ, and explain their implications on a routing infrastructure, then you are not yet competent to determine whether or not your favorite routing protocol is adequate to the task of providing routing in a homenet.

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2015 22:21:58 +0200

Hi,

On Tue, Jul 28, 2015 at 11:55:16AM -0400, Ted Lemon wrote:
> This means that the end user can be assumed to plug home routers together 
> in arbitrary topologies, [..]
> 
> Our goal is for this to work in a multihomed IPv6 environment.   

Just to repeat myself from yesterday :-) - OpenWRT with HNCP and Babels
achieved this nicely enough 15+ months ago.  Yes, it had some rough
edges, but it *worked*.

Then this working group started to go into full committee mode about
"can we not use some other routing protocol instead, plese?" instead of
working with and improving the existing stuff and getting the documents
done and standardized...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Jul 2015 23:44:51 +0000

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2015 10:24 AM
To: Hemant Singh (shemant); [email-masked]
Subject: RE: some IS-IS questions

>BTW, I did do a quick price scan of Cisco ASR 9000 series routers, and believe they may be just a little bit outside the range of the average consumer. So I don't know if it would be reasonable to find this >RCMD functionality in a consumer-grade router.

Sorry, I sent a new tinyrul for the URL.  Indeed the asr9k is a high-end Cisco router.  

>So when IS-IS talks about topology discovery, it's talking about router topology, with no knowledge of hosts or bridges or PHY technologies. I'm sorry, but in a home network, the router topology is really >the least of my worries.

Correct.

>So the answer is no. Bridges are not going to be discovered in a homenet IS-IS topology.

A bridge does issue ARP to a switch/router  The switch/router learns the mac-address of the bridge and the bridged domain.  The switch/router propagates the learnt information in a sub-TLV of ISIS that supports a mac-address.  One can always add a new sub TLV to carry bridge mac-address information and other data (bridged domain) in ISIS messages.  

>No, this does not suffice. I'll have to spend some time putting together my physical layer examples. In short, the vast majority of problems in the home network are due to issues of physical connectivity ->- links go up and down causing consumer electronics devices to "lose" their IP address(es) and stop working until something kicks the device's network interface to get an IP address again (with reboot >being the easiest and most-likely-to-work form of kicking).

Agree.   So a routing protocol which is good at detecting link up/down and also supports fast detection would be useful in the home LAN.   ISIS certainly meets this goal.  ISIS is also extensible because it uses TLV and sub TLV and thus supporting bridges in ISIS is possible as described above.  ISIS can also avoid loops.  However, a distance vector routing protocol can also detect link up/down state and can also avoid routing loops.  Babel is a distance vector protocol.  I haven't read it to see its specific details for loop avoidance and how fast can it detect link up/down.
If you really want reliable and few  orders of magnitude better (vs. routing protocols) link up/down detection, use BFD (RFC 5880).  BFD is simple enough to support on a CE consumer router and supports msec link up/down detection.  

>1. Whatever diagnostics / topology discovery mechanisms may exists in IS-IS are insufficient to be of any real use. So any argument for IS-IS based on the existence of such diagnostics is irrelevant. 

Unless someone shows me ISIS diags simple enough to be used in a retail consumer device, even I am sold on what you say above.

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 29 Jul 2015 13:57:12 +0000

> A bridge does issue ARP to a switch/router  The switch/router learns the
> mac-address of the bridge and the bridged domain.  The switch/router
> propagates the learnt information in a sub-TLV of ISIS that supports a mac-
> address.  One can always add a new sub TLV to carry bridge mac-address
> information and other data (bridged domain) in ISIS messages.

So, a possible feature extension to IS-IS to do something it doesn't do today?
No thanks.
At Bits 'n' Bites there were homenet demos with IS-IS implementations. 
I really would like to know exactly what those do, since those seem to be what's meant by "IS-IS as the homenet routing protocol".
I'm not at all interested in hypothetical homenet IS-IS implementations, or what IS-IS could maybe possibly do if we spent a few years improving it.
Barbara

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 29 Jul 2015 16:13:46 +0200

Hello Barbara,

David published the draft you are looking for IS-IS:
https://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00 <https://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00>
I am not sure it does everything we have been talking about though (Like automatic metrics and such).

Concerning Babel what you need is:
- RFC6126 (Babel)
- RFC7557 (Extension mechanism for Babel)
- draft-boutier-babel-source-specific-01 (src-dst routing)

- Pierre

> Le 29 juil. 2015 à 15:57, STARK, BARBARA H <[email-masked]> a écrit :
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 29 Jul 2015 14:35:41 +0000

Perfect! Thanks. I’d missed that. Yes, that’s exactly what I was looking for.

So when the Design Team compares IS-IS to Babel, they really should be comparing https://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00 to RFC6126+RFC7557+draft-boutier-babel-source-specific-01.

Any other IS-IS comparison would involve a hypothetical IS-IS. Since a hypothetical IS-IS, by definition, does not exist, a hypothetical IS-IS would fail the criterion that requires examination only of existing IGPs.

If discussion of what IS-IS actually does could be limited to discussion of the very concrete proposal in https://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00, I think that would help the discussion a lot. Functionality not in the draft should not be claimed and should not be used as a point of comparison.

If someone would like for some different concrete proposal to be considered, then I think they’d better propose it fast, so the Design Team can consider it.
Barbara

From: Pierre Pfister [mailto:[email-masked]]
Sent: Wednesday, July 29, 2015 10:14 AM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [homenet] some IS-IS questions

Hello Barbara,

David published the draft you are looking for IS-IS:
https://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00
I am not sure it does everything we have been talking about though (Like automatic metrics and such).

- Pierre

Le 29 juil. 2015 à 15:57, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> a écrit :

So the answer is no. Bridges are not going to be discovered in a homenet IS-
IS topology.

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 29 Jul 2015 17:43:15 +0300

On 29.7.2015, at 17.35, STARK, BARBARA H <[email-masked]> wrote:
> So when the Design Team compares IS-IS to Babel, they really should be comparinghttps://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00 to RFC6126+RFC7557+draft-boutier-babel-source-specific-01.
> 
>  
> 
> Any other IS-IS comparison would involve a hypothetical IS-IS. Since a hypothetical IS-IS, by definition, does not exist, a hypothetical IS-IS would fail thecriterion that requires examination only of existing IGPs.

First of all, thanks from me to David L. as well for the document; I love having it around.

I think the metric stuff is missing from that at least (although they are ‘wide’ which helps I guess to express 10 better); so we’re dealing with fixed default metric IS-IS configuration here.

It seems to be also missing security.

And to echo Barbara, if that is not the plan, now would be good time to update the document.

Cheers,

-Markus

---

From: Steven Barth <[email-masked]>
Date: Wed, 29 Jul 2015 17:06:44 +0200

> If someone would like for some different concrete proposal to be considered, then I think they’d better propose it fast, so the Design Team can consider it.

Since we went full-circle already at least once, there have been other efforts in the past to "tame the beast"
for homenet. There was e.g. Christian Hopps' writeup in connection with the comparison draft back in March, e.g.

https://tools.ietf.org/html/draft-mrw-homenet-rtg-comparison-02#page-5
https://www.mail-archive.com/[email-masked]/msg04270.html

I haven't compared those to David's in full detail yet, on fist glance David's variant looks a bit
more detailed (references more extensions). I'm no expert here to evaluate what the actual differences
are, at first glance, Christian's variant seemed to be a bit more traditional where as David's uses some
more experimental extensions such as IPv6-transport and Point to Multipoint where as Christian also
mentioned security extensions for authentication.

While I'm glad about both writeups, I think there might be a need for consensus of the IS-IS experts about
what should be in and what should be out to proceed in a sane manner (if there isn't already).

Cheers,

Steven

---

From: Tim Chown <[email-masked]>
Date: Fri, 31 Jul 2015 15:33:03 +0100

> achieved this nicely enough 15+ months ago.  Yes, it had some rough

And maybe a year before that there was working code for OSPF (with multiple 
implementations based on at least Bird and Quagga) which had working code 
for homenet routing, including automatic prefix configuration and src/dst routing.

Hindsight is a wonderful thing. If homenet had decided to separate out the
configuration from the routing at an earlier point, we’d certainly have been
where we are now rather sooner. The OSPF implementations allowed us to
see quite clearly that the separation of configuration was desirable (as much
as Markus was increasingly creative with new TLVs!), so that experience
while arguably ‘lost’ time was something we learnt from. Part of the homenet
journey.

Personally, I like where we are with Babel and HNCP now. Many of the same
people, esp. Markus and Dave, who prototyped previous work, have been 
awesome in repeating their efforts for HNCP & Babel, and that’s great.

It was a shame to see many open source developers feeling frustrated at
Prague. I hope they do continue their efforts. We would not be where we
are now in homenet without them. The HNCP work should now be able to be
completed independently of the routing protocol chosen, and if the Babel
side meeting from Prague leads to wider understanding of Babel, and its
standards status being elevated, that would be great.

Tim