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

From: Jeff Parker <[email-masked]>
Date: Wed, 5 Sep 2001 12:30:59 -0400

Ken -
	Interesting point.  I've trimmed your 
note to oblivion.  A few questions:

> (10.10.10.0) [A]<L1/L2>[B]<L1/L2>[C]<L1/L2>[D] (11.11.11.0)

	As I read your description of the problem,
you have a string of routers, and only one possible
path from A to D.  You are re-interpreting for IP
the rule in 7.2.8.1 (Computing routes through 
overloaded Intermediate systems) The concern is
that in B's overloaded state, it may think that 
the 11 network is reachable via A, so B should
never be used as a transit router.   

	I am trying to understand the proposed solution. 
Are you suggesting that an overloaded router include 
directly attached networks in LSP 0, and indirectly l
earned networks in later LSPs?  Or that overloaded 
routers should not advertise such routes, as no-one
should trust them?  

	I assume that this change requires a "flag day"
when all routers upgrade, as a difference of opinion
about the validity of these routes can cause black
holes (Example above: D is old school, C is new)

	I have missed the meaning of the phrase 
"source systemID" on your proposed change, 
line 2 (text below).  Does it belong there?
 
	What do we do if we cannot fit all relevant 
networks in LSP 0?  

	What is the interaction between this commandment
and section 7.3.4.4, the admonition to try to keep
adjacency information in the same segment?  

- jeff parker
- axiowave networks
- If triangles had a God, he would have 3 sides.

> -----Original Message-----
> From: Ken Larmer [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2001 3:50 PM
> To: Isis-Wg@Spider. Juniper. Net
> Cc: Ken Larmer; Chuck Ouimette; Mike Shand
> Subject: RE: [Isis-wg] L2 LSP IP Internal Reachability Information TLV
> contents
> 
> 
> 
> I am ... trying
> to understand if we have a potential RFC-1195 protocol deficiency 
> [about how] RFC-1195 Annex C Dijkstra Calculation 
> treats IP Reachable addresses.

...

> Proposed resolution:
> 
> RFC-1195 currently states:
> 
> 	L2 LSP
> 
> 	IP Internal Reachability Information -- IP addresses 
> within the routing
> 	domain reachable directly via one or more interfaces 
> on this Intermediate system.
> 
> Proposed Change to RFC-1195
> 
> 	Begin:
> 
> 	L2 LSP
> 
**> 	If source systemID, LSP number = 0, LSPDB OVL = 0;
> 
> 	IP Internal Reachability Information -- IP addresses 
> within the routing domain reachable directly via one or 
> more interfaces on this Intermediate system.
> 
> 	Otherwise;
> 
> 	IP Internal Reachability Information -- IP addresses 
> directly attached to one or more interfaces on this 
> Intermediate system. 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Ken Larmer" <[email-masked]>
Date: Wed, 5 Sep 2001 14:40:14 -0400

Hi Jeff,

	I re-read what I sent to the list as a fix and it makes no sense to me
either! Sorry, I transposed some stuff from another email message. Let me
try to explain the proposed fix with different, more comprehensible, text
:^)

Replace the text in RFC-1195, section 5.3.5 Level 2 Link State PDU, Internal
Reachability Information with the following text:

Current text from this section:

IP Internal Reachability Information -- IP addresses within the routing
domain reachable directly via one or more interfaces on this Intermeditate
system.

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

	Jeff, I believe that this would fix this problem and it would also have the
benefit of reducing the amount of traffic being originated by a "supposedly"
unreliable IS. 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. This situation is
addressed by the If statement "local L1 LSP number = 0, ovl bit = 1". I am
not sure how we would address the situation when a L1 LSPDB ovl bit is being
set manually? In this case, we would not want to prevent L2 LSPs from
advertising IP Reachable addresses derived from L1 LSPs in the same area.
Perhaps we could incorporate a check to see if the ovl bit is being set
manually, though I am not sure how we would accomplish that???

	Of course, if the L2 LSPDB is encountering an overload condition, as long
as the L1 LSPDB is fine, the IP Reachable address information we place in
the L2 LSP should still be accurate. Though this would still mean that this
IS could be used as a transient IS because of this bug. In addition, with
the concept of being able to manually set the OVL bit, operators are
expecting that this IS would NOT be used as a transient IS. Consequently,
the second part of the If statement "local L2 LSP number = 0, ovl bit = 1"
is required to prevent this IS from being used as a transient IS when the L2
LSPDB is actually encountering an overload condition or when the L2 LSPDB
ovl bit has been set manually.

	I hope this makes sense?

Cheers,
Ken Larmer