Subject: RE: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents

From: Jeff Parker <[email-masked]>
Date: Wed, 5 Sep 2001 16:52:55 -0400

> Proposed replacement text:
> 
> If
> 	local L1 LSP number = 0, ovl bit = 1
> 	or
> 	local L2 LSP number = 0, ovl bit = 1
> then
> 	IP Internal Reachability Information = IP addresses 
> directly attached to one or more interfaces on this 
> Intermediate system
> else
> 	IP Internal Reachability Information = IP addresses 
> within the routing domain reachable directly via one 
> or more interfaces on this Intermeditate system
> end

As an editorial comment, this might be clearer if you
drop the last "directly".  What you are saying is
that you can reach this somehow, i.e. perhaps
indirectly.

> So, when a local IS detects that it no longer 
> has enough space to store L1 LSPs, it should 
> not bother advertising partial information
> derived from an incomplete L1 LSPDB in its L2 LSPs. 

I've always figured that overloaded at level X meant
overloaded everywhere.  I can imagine implementations
that are smart enough to segregate memory, but if you
have an L1/L2 router that is in trouble at Level n, 
it is probably in trouble at Level 3-n.  

> Perhaps we could incorporate a check to see if the ovl bit is 
> being set manually...???

I'm not sure who 'we' are in the sentence above, but there
is only one bit currently, and there is no way for
a remote router to tell why the overload bit is set.  
Of course you may have meant the local IGP...

At issue here is how much you can trust a router who
knows enough to know that it can't be trusted fully.
What you are saying is

	These are addresses that I know I can reach without
	full information - a generalization of host addresses.

Your scheme puts these addresses in segment 0.  
I am still unclear about the other addresses.  
I can imagine two behaviors

	o Don't send remote networks until you get out of 
	  overload.  This has the advantage that we 
	  don't need to modify old routers: this 
	  info isn't there, so there is no temptation
        to use it

	o Send information about remote networks 
	  in later LSP segments, so that the information
	  has time to flood through the network, and then
	  send out LSP segment 0 with the overload bit
	  clear.  

The first seems much safer, if a bit slower to converge.  
It also requires no change in the protocol, and only
requires that routers be careful in what they originate. 
Would that solve your problem?   

- jeff parker
- axiowave networks
 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Ken Larmer" <[email-masked]>
Date: Thu, 6 Sep 2001 10:42:56 -0400

Hi Jeff,

	Thanks for the comments, my responses are in-line.

> that you can reach this somehow, i.e. perhaps

Not really, what I am saying is "only advertise those IP subnets which are
directly attached to the router which is advertising them". Indirectly would
imply, to me at least, IP subnets which are also reachable via L1 and since
L1 information is taken from the L1 LSPs, which make up that area, this
would result in the same behavior. Does this make sense?

> it is probably in trouble at Level 3-n.

I agree with this statement given the current implementations. However,
wouldn't  we be limiting new implementations if we did not treat L1 and L2
LSPDBs as being separate with the potential for allocating different
resources for each?

> Of course you may have meant the local IGP...

I'm sorry, by "we", I meant IETF IS-WG. Yes, I did mean the local IS and not
remote ISs. Jeff, the problem as I see is not that the remote ISs calculate
their routes through this IS incorrectly (though an argument could me made
for that, though that would me changing RFC-1195s interpretation of
Dijkstra). It is the local IS with the overload condition which is
advertising L1 IP reachable addresses within L2 LSPs which is the issue! If
the local IS did not advertise these routes, I believe there wouldn't be a
possible backdoor through an overload L1/L2 IS.

Jeff, I believe the above is a result of the way RFC-1195, annex C processes
local IP Reachable addresses (local to the IS running the calculation).
RFC-1195, Annex C states the following:

C.1.4 The Algorithm

	1) Add <SELF,0,W> to PATHS, where W is a special value indicating
	traffic to SELF is passed up to internal processes (rather than
	forwarded).

	2) Now pre-load TENT with the local adjacency database (Each
	entry made to TENT must be marked as being either an End System
	or a router to enable the check at the end of Step 2 to be made
	correctly - Note that each local IP reachability entry is
	included as an adjacency, and is marked as being an End System).
...
...

	Step 1: Examine the zeroeth link state PDU of P, the system just
	placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID
	as P, and LSP number zero).

	1) If this LSP is present, and the "Infinite Hippity Cost" bit is
	clear, then for each LSP of P (i.e., all LSPs with the same
	first 7 octets of LSPID and P, irrespective of the value of
	LSP number) compute:

		dist(P,N) = d(P) + metric.k(P,N)

	for each neighbor N (both End System and router) of the system P. If
	the "Infinite Hippity Cost" bit is set, only consider the End System
	neighbors of the system P. Note that the End Systems neighbors of the
	system P includes IP reachable address entries included in the LSPs
	from system P.
...
...

From what I can determine, because the local IS is added to PATHS first, the
check to see if the "Infinite Hippity Cost" bit is set, does not take place.
It only takes place for subsequent ISs which are added to PATHS. Let me know
if I am misinterpreting this section of Annex C?

> 	full information - a generalization of host addresses.

Yes, this is correct!

> I can imagine two behaviors

Jeff, the reason I am suggesting we check local LSPs, LSP number = 0, ovl
=1, is because, in accordance with ISO-10589, this is the only LSP number
for which we should set this bit. Regardless of how many L2 LSPs an overload
IS generates, it will check to see if its LSP number = 0, ovl = 1. If it is,
that IS will only generate as many L2 LSPs as required to advertise the
directly attached IP subnets. Conversely, if the local LSP number = 0, ovl =
0, that same IS will generate as many L2 LSPs as is required to fit all of
the reachable IP subnets within the local area.

Does that make sense?

> Would that solve your problem?

Yes, I agree! One other point though. If we do not originate this
information from an overloaded IS, remote ISs will not have to calculate
these routes. This is goodness in my opinion because if we actually have an
IS, which is overloaded, we don't really want to trust its advertised
information. Of course, except for the attached IP subnets. Though, given
the right circumstances, even that information may be questionable?

In addition, if we manually set the ovl bit, we are more than likely doing
this because we are either testing this IS or we want to wait until we have
more routes before we allow remote ISs to use this IS as a transient IS. The
problem is that we still advertise the information we already possess and
remote ISs unnecessarily process this information. If we were to remove this
questionable information from the L2 LSPs and only add it when the ovl bit
is cleared, we would lesson the amount of processing remote ISs would have
to process until the remote IS in question was no longer advertising a LSPDB
overload condition.

Actually Jeff, I can think of several different ways we can lesson the
impact of an overloaded IS on the rest of the network if we don't consider
locally attached IP subnet information to be reliable. We could eliminate
advertisement of any IP Reachable subnets until that IS is no longer in the
LSPDB overload condition. Wouldn't advertisement of the IP Interface
information be sufficient for remote management capabilities?

One final point. I found this "potential" bug while conducting
interoperability tests in our lab. I would feel much more comfortable
proceeding ahead if someone else were to verify this problem in their lab.
Conceptually it all makes sense, but I strongly suggest we have some
additional verification for this "potential" bug prior to looking for a fix!

Cheers,
Ken Larmer

---

From: Naiming Shen <[email-masked]>
Date: Thu, 06 Sep 2001 09:43:13 -0700

Ken,

	It seems to me more like an implementation issue, I at least
know more than one venders do this correctly.

	This problem does not need to be only happening on L2 LSPs of
a L1/L2 border router(to borrow an ospf term), when a router originating
it's own LSPs, it has three sources for it's IP tlv:

  (1) it's own IP subnets on interfaces
  (2) route leaking between levels, either L2 routes leaks down into L1
      or L1 routes leaks up into L2 domain, this only happens on L1/L2
      border routers.
  (3) external IP routes redistributed into ISIS on either levels.

	When an ISIS router is in "normal" condition, it can possibly
do any or all the the three above while building it's own LSPs, but when
a router is or claims in an "overload" condition, and if it is able to
update and send out newer version of it's LSPs, it should only do the
first one, and skip the next two if is configured to do so.

	But it's a good idea to document this somewhere. Thanks.

 ]Hi Jeff,
 ]
 ]	Thanks for the comments, my responses are in-line.
 ]
 ]> > Proposed replacement text:
 ]> >
 ]> > If
 ]> > 	local L1 LSP number = 0, ovl bit = 1
 ]> > 	or
 ]> > 	local L2 LSP number = 0, ovl bit = 1
 ]> > then
 ]> > 	IP Internal Reachability Information = IP addresses
 ]> > directly attached to one or more interfaces on this
 ]> > Intermediate system
 ]> > else
 ]> > 	IP Internal Reachability Information = IP addresses
 ]> > within the routing domain reachable directly via one
 ]> > or more interfaces on this Intermeditate system
 ]> > end
 ]>
 ]> As an editorial comment, this might be clearer if you
 ]> drop the last "directly".  What you are saying is
 ]> that you can reach this somehow, i.e. perhaps
 ]> indirectly.
 ]
 ]Not really, what I am saying is "only advertise those IP subnets which are
 ]directly attached to the router which is advertising them". Indirectly would
 ]imply, to me at least, IP subnets which are also reachable via L1 and since
 ]L1 information is taken from the L1 LSPs, which make up that area, this
 ]would result in the same behavior. Does this make sense?
 ]
 ]> > So, when a local IS detects that it no longer
 ]> > has enough space to store L1 LSPs, it should
 ]> > not bother advertising partial information
 ]> > derived from an incomplete L1 LSPDB in its L2 LSPs.
 ]>
 ]> I've always figured that overloaded at level X meant
 ]> overloaded everywhere.  I can imagine implementations
 ]> that are smart enough to segregate memory, but if you
 ]> have an L1/L2 router that is in trouble at Level n,
 ]> it is probably in trouble at Level 3-n.
 ]
 ]I agree with this statement given the current implementations. However,
 ]wouldn't  we be limiting new implementations if we did not treat L1 and L2
 ]LSPDBs as being separate with the potential for allocating different
 ]resources for each?
 ]
 ]> > Perhaps we could incorporate a check to see if the ovl bit is
 ]> > being set manually...???
 ]>
 ]> I'm not sure who 'we' are in the sentence above, but there
 ]> is only one bit currently, and there is no way for
 ]> a remote router to tell why the overload bit is set.
 ]> Of course you may have meant the local IGP...
 ]
 ]I'm sorry, by "we", I meant IETF IS-WG. Yes, I did mean the local IS and not
 ]remote ISs. Jeff, the problem as I see is not that the remote ISs calculate
 ]their routes through this IS incorrectly (though an argument could me made
 ]for that, though that would me changing RFC-1195s interpretation of
 ]Dijkstra). It is the local IS with the overload condition which is
 ]advertising L1 IP reachable addresses within L2 LSPs which is the issue! If
 ]the local IS did not advertise these routes, I believe there wouldn't be a
 ]possible backdoor through an overload L1/L2 IS.
 ]
 ]Jeff, I believe the above is a result of the way RFC-1195, annex C processes
 ]local IP Reachable addresses (local to the IS running the calculation).
 ]RFC-1195, Annex C states the following:
 ]
 ]C.1.4 The Algorithm
 ]
 ]	1) Add <SELF,0,W> to PATHS, where W is a special value indicating
 ]	traffic to SELF is passed up to internal processes (rather than
 ]	forwarded).
 ]
 ]	2) Now pre-load TENT with the local adjacency database (Each
 ]	entry made to TENT must be marked as being either an End System
 ]	or a router to enable the check at the end of Step 2 to be made
 ]	correctly - Note that each local IP reachability entry is
 ]	included as an adjacency, and is marked as being an End System).
 ]...
 ]...
 ]
 ]	Step 1: Examine the zeroeth link state PDU of P, the system just
 ]	placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID
 ]	as P, and LSP number zero).
 ]
 ]	1) If this LSP is present, and the "Infinite Hippity Cost" bit is
 ]	clear, then for each LSP of P (i.e., all LSPs with the same
 ]	first 7 octets of LSPID and P, irrespective of the value of
 ]	LSP number) compute:
 ]
 ]		dist(P,N) = d(P) + metric.k(P,N)
 ]
 ]	for each neighbor N (both End System and router) of the system P. If
 ]	the "Infinite Hippity Cost" bit is set, only consider the End System
 ]	neighbors of the system P. Note that the End Systems neighbors of the
 ]	system P includes IP reachable address entries included in the LSPs
 ]	from system P.
 ]...
 ]...
 ]
 ]>From what I can determine, because the local IS is added to PATHS first, the
 ]check to see if the "Infinite Hippity Cost" bit is set, does not take place.
 ]It only takes place for subsequent ISs which are added to PATHS. Let me know
 ]if I am misinterpreting this section of Annex C?
 ]
 ]> At issue here is how much you can trust a router who
 ]> knows enough to know that it can't be trusted fully.
 ]> What you are saying is
 ]>
 ]> 	These are addresses that I know I can reach without
 ]> 	full information - a generalization of host addresses.
 ]
 ]Yes, this is correct!
 ]
 ]> Your scheme puts these addresses in segment 0.
 ]> I am still unclear about the other addresses.
 ]> I can imagine two behaviors
 ]
 ]Jeff, the reason I am suggesting we check local LSPs, LSP number = 0, ovl
 ]=1, is because, in accordance with ISO-10589, this is the only LSP number
 ]for which we should set this bit. Regardless of how many L2 LSPs an overload
 ]IS generates, it will check to see if its LSP number = 0, ovl = 1. If it is,
 ]that IS will only generate as many L2 LSPs as required to advertise the
 ]directly attached IP subnets. Conversely, if the local LSP number = 0, ovl =
 ]0, that same IS will generate as many L2 LSPs as is required to fit all of
 ]the reachable IP subnets within the local area.
 ]
 ]Does that make sense?
 ]
 ]> 	o Don't send remote networks until you get out of
 ]> 	  overload.  This has the advantage that we
 ]> 	  don't need to modify old routers: this
 ]> 	  info isn't there, so there is no temptation
 ]>         to use it
 ]>
 ]> 	o Send information about remote networks
 ]> 	  in later LSP segments, so that the information
 ]> 	  has time to flood through the network, and then
 ]> 	  send out LSP segment 0 with the overload bit
 ]> 	  clear.
 ]>
 ]> The first seems much safer, if a bit slower to converge.
 ]> It also requires no change in the protocol, and only
 ]> requires that routers be careful in what they originate.
 ]> Would that solve your problem?
 ]
 ]Yes, I agree! One other point though. If we do not originate this
 ]information from an overloaded IS, remote ISs will not have to calculate
 ]these routes. This is goodness in my opinion because if we actually have an
 ]IS, which is overloaded, we don't really want to trust its advertised
 ]information. Of course, except for the attached IP subnets. Though, given
 ]the right circumstances, even that information may be questionable?
 ]
 ]In addition, if we manually set the ovl bit, we are more than likely doing
 ]this because we are either testing this IS or we want to wait until we have
 ]more routes before we allow remote ISs to use this IS as a transient IS. The
 ]problem is that we still advertise the information we already possess and
 ]remote ISs unnecessarily process this information. If we were to remove this
 ]questionable information from the L2 LSPs and only add it when the ovl bit
 ]is cleared, we would lesson the amount of processing remote ISs would have
 ]to process until the remote IS in question was no longer advertising a LSPDB
 ]overload condition.
 ]
 ]Actually Jeff, I can think of several different ways we can lesson the
 ]impact of an overloaded IS on the rest of the network if we don't consider
 ]locally attached IP subnet information to be reliable. We could eliminate
 ]advertisement of any IP Reachable subnets until that IS is no longer in the
 ]LSPDB overload condition. Wouldn't advertisement of the IP Interface
 ]information be sufficient for remote management capabilities?
 ]
 ]One final point. I found this "potential" bug while conducting
 ]interoperability tests in our lab. I would feel much more comfortable
 ]proceeding ahead if someone else were to verify this problem in their lab.
 ]Conceptually it all makes sense, but I strongly suggest we have some
 ]additional verification for this "potential" bug prior to looking for a fix!
 ]
 ]Cheers,
 ]Ken Larmer
 ]
 ]_______________________________________________
 ]Isis-wg mailing list  -  [email-masked]
 ]http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming

---

From: "Ken Larmer" <[email-masked]>
Date: Fri, 7 Sep 2001 09:30:57 -0400

> know more than one venders do this correctly.

Thanks Naiming, I noticed that same behavior also!

Cheers,
Ken Larmer