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

From: May Lu <[email-masked]>
Date: Sat, 22 Sep 2001 15:38:49 -0500

Naiming,

In you previous e-mail, the 3rd type of sources may comes from different
protocols that are redistributed into ISIS. It may contains directly
connected routes, statically configured routes and routes redistributed from
other protocols. If the router is or claims in an "overload" condition,
should it still include the redistributed directly connected routes and
statically routes?

Xiaomei Lu

-----Original Message-----
From: Naiming Shen [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 11:43 AM
To: Ken Larmer
Cc: Isis-Wg@Spider. Juniper. Net; Jeff Parker; Chuck Ouimette
Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV
contents 

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
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.

---------------------------------------------------------

---

From: Naiming Shen <[email-masked]>
Date: Mon, 24 Sep 2001 10:57:20 -0700

Yes, it makes sense to allow redistributed source from connected or
static through. So this is very implementation related, and one can
have knobs to do so. But a good practice is to aggragate connected
and static routes on the router then import them into ibgp instead
of into igp.

 ]--=_IS_MIME_Boundary
 ]Content-Type: text/plain;
 ]	charset="iso-8859-1"
 ]
 ]Naiming,
 ]
 ]In you previous e-mail, the 3rd type of sources may comes from different
 ]protocols that are redistributed into ISIS. It may contains directly
 ]connected routes, statically configured routes and routes redistributed from
 ]other protocols. If the router is or claims in an "overload" condition,
 ]should it still include the redistributed directly connected routes and
 ]statically routes?
 ]
 ]Xiaomei Lu
 ]
 ]
 ]-----Original Message-----
 ]From: Naiming Shen [mailto:[email-masked]]
 ]Sent: Thursday, September 06, 2001 11:43 AM
 ]To: Ken Larmer
 ]Cc: Isis-Wg@Spider. Juniper. Net; Jeff Parker; Chuck Ouimette
 ]Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV
 ]contents 
 ]
 ]
 ]
 ]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.
 ]
 ]

- Naiming

---

From: Tony Li <[email-masked]>
Date: Tue, 25 Sep 2001 02:24:04 -0700

Interesting...

If the router is truly in an overload state, I would tend to want as much
traffic to shy away from it as possible.  This is just because overloaded
routers tend to behave Very Predictably.  Also Very Badly.  ;-)

If the router is instead in overload to avoid carrying transit traffic,
then I would also want to not advertise routes that would tend to ADD
transit traffic.

In my grokking of 10589, the only reason to advertise anything is to allow
reachability to ESes behind a single overloaded router.  The direct analog
in IP would only to allow interface prefixes (or redistribute connected).
I'd argue that even redistrubted static routes are more likely to be in the
transit class.

Tony

Naiming Shen writes:
 | 
 | Yes, it makes sense to allow redistributed source from connected or
 | static through. So this is very implementation related, and one can
 | have knobs to do so. But a good practice is to aggragate connected
 | and static routes on the router then import them into ibgp instead
 | of into igp.
 | 
 |  ]--=_IS_MIME_Boundary
 |  ]Content-Type: text/plain;
 |  ]	charset="iso-8859-1"
 |  ]
 |  ]Naiming,
 |  ]
 |  ]In you previous e-mail, the 3rd type of sources may comes from different
 |  ]protocols that are redistributed into ISIS. It may contains directly
 |  ]connected routes, statically configured routes and routes redistributed from
 |  ]other protocols. If the router is or claims in an "overload" condition,
 |  ]should it still include the redistributed directly connected routes and
 |  ]statically routes?
 |  ]
 |  ]Xiaomei Lu
 |  ]
 |  ]
 |  ]-----Original Message-----
 |  ]From: Naiming Shen [mailto:[email-masked]]
 |  ]Sent: Thursday, September 06, 2001 11:43 AM
 |  ]To: Ken Larmer
 |  ]Cc: Isis-Wg@Spider. Juniper. Net; Jeff Parker; Chuck Ouimette
 |  ]Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV
 |  ]contents 
 |  ]
 |  ]
 |  ]
 |  ]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.
 |  ]
 |  ]
 | 
 | - Naiming
 | _______________________________________________
 | Isis-wg mailing list  -  [email-masked]
 | http://external.juniper.net/mailman/listinfo/isis-wg
 | _______________________________________________
 | Isis-wg-external mailing list
 | [email-masked]
 | http://mailist.procket.com/mailman/listinfo/isis-wg-external
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Tue, 25 Sep 2001 11:28:17 -0700

Agreed the static redistribution is not as clear as the connected, that's
why I suggested zillions of knobs to control this "overload bit" feature;-)
If a non-bgp customer of an ISP has it's own address space, then usually
static route is used in this case, even though the preferable way is to
inject this static into ibgp, but if the ISP likes to inject this into
IGP, then it would be good to redistribute them even in "oeveload" state
since this may be the only way to reach this customer. Yes, only the users
can really decide how the static route is being used in their network.

Another way of looking at this; since the router needs to redistribute
connect and static into igp, then it's an edge router. so this bgp
related "overload" feature should be disabled on this router, since it
usually does not handle transit traffic.

last one is of course we never have to consider bgp related "overload",
since everything at least in "millisecond or nanosecond convergence",
before we have time to build LSP, the routing is already converged...

 ]
 ]
 ]Interesting...
 ]
 ]If the router is truly in an overload state, I would tend to want as much
 ]traffic to shy away from it as possible.  This is just because overloaded
 ]routers tend to behave Very Predictably.  Also Very Badly.  ;-)
 ]
 ]If the router is instead in overload to avoid carrying transit traffic,
 ]then I would also want to not advertise routes that would tend to ADD
 ]transit traffic.
 ]
 ]In my grokking of 10589, the only reason to advertise anything is to allow
 ]reachability to ESes behind a single overloaded router.  The direct analog
 ]in IP would only to allow interface prefixes (or redistribute connected).
 ]I'd argue that even redistrubted static routes are more likely to be in the
 ]transit class.
 ]
 ]Tony
 ]
 ]Naiming Shen writes:
 ] | 
 ] | Yes, it makes sense to allow redistributed source from connected or
 ] | static through. So this is very implementation related, and one can
 ] | have knobs to do so. But a good practice is to aggragate connected
 ] | and static routes on the router then import them into ibgp instead
 ] | of into igp.
 ] | 
 ] |  ]--=_IS_MIME_Boundary
 ] |  ]Content-Type: text/plain;
 ] |  ]	charset="iso-8859-1"
 ] |  ]
 ] |  ]Naiming,
 ] |  ]
 ] |  ]In you previous e-mail, the 3rd type of sources may comes from different
 ] |  ]protocols that are redistributed into ISIS. It may contains directly
 ] |  ]connected routes, statically configured routes and routes redistributed 
from
 ] |  ]other protocols. If the router is or claims in an "overload" condition,
 ] |  ]should it still include the redistributed directly connected routes and
 ] |  ]statically routes?
 ] |  ]
 ] |  ]Xiaomei Lu
 ] |  ]
 ] |  ]
 ] |  ]-----Original Message-----
 ] |  ]From: Naiming Shen [mailto:[email-masked]]
 ] |  ]Sent: Thursday, September 06, 2001 11:43 AM
 ] |  ]To: Ken Larmer
 ] |  ]Cc: Isis-Wg@Spider. Juniper. Net; Jeff Parker; Chuck Ouimette
 ] |  ]Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV
 ] |  ]contents 
 ] |  ]
 ] |  ]
 ] |  ]
 ] |  ]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.
 ] |  ]
 ] |  ]
 ] | 
 ] | - Naiming
 ] | _______________________________________________
 ] | Isis-wg mailing list  -  [email-masked]
 ] | http://external.juniper.net/mailman/listinfo/isis-wg
 ] | _______________________________________________
 ] | Isis-wg-external mailing list
 ] | [email-masked]
 ] | http://mailist.procket.com/mailman/listinfo/isis-wg-external
 ]_______________________________________________
 ]Isis-wg mailing list  -  [email-masked]
 ]http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 26 Sep 2001 15:06:00 -0400

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tony Li
> Sent: Tuesday, September 25, 2001 5:24 AM
> To: Naiming Shen
> Cc: May Lu; Isis-Wg@Spider. Juniper. Net
> Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability 
> Information TLV con tents 
> 
> 
> 
> 
> Interesting...
> 
> If the router is truly in an overload state, I would tend to 
> want as much traffic to shy away from it as possible.  This 
> is just because overloaded routers tend to behave Very 
> Predictably.  Also Very Badly.  ;-)
> 
> If the router is instead in overload to avoid carrying 
> transit traffic, then I would also want to not advertise 
> routes that would tend to ADD transit traffic.
> 
> In my grokking of 10589, the only reason to advertise 
> anything is to allow reachability to ESes behind a single 
> overloaded router.  The direct analog in IP would only to 
> allow interface prefixes (or redistribute connected). I'd 
> argue that even redistrubted static routes are more likely to 
> be in the transit class.
>
Just to give the historical motivation, the idea was to maximize the
probability network management would work to reach through a busted
router by chaining Telnets or SNMP through the reachable ESs. The
"cause" of the problem might be some other router than the one in
overload state.
 
Dave.