Subject: [Isis-wg] RE: Need for isisRedistributeAddrTable

From: Jeff Parker <[email-masked]>
Date: Wed, 9 Oct 2002 11:35:00 -0400

> We can use [the isisRedistributeAddrTable]
> the table to show what routes "are" being leaked based on policies
> for leaking that are defined elsewhere.  We can keep the ExistState
> attribute, although some implementation may not allow it to be
> controlled via SNMP.
> 
> We should also include an isisRedistributeType attribute (not part
> of the index) for controlling whether this route prefix is automatic
> or manual.  Some implementation will not allow this to be set via
> SNMP either (they'll always have only automatic routes in this table).

I guess I am not following this.  This table is to manager L2 to L1
leaking.  If you want to leak a static route into L1, I don't
think this is the place to define that.  

We have skirted the whole issue of route policy as being very
proprietary.  

> Finally, we should dual-purpose the table and also show which 
> routes are being leaked from L1 into L2 as well.   

Laura addressed this previously.  
The summary has been around for a long time, 
and covers that case.  See if it has what you need.

- jeff parker
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: "Don Goodspeed" <[email-masked]>
Date: Wed, 9 Oct 2002 16:01:00 -0400 (EDT)

Jeff and all,

But not everyone supports summaries, and most support leaking via
route policies.  Also, leaking does go the other way since
L1 externals are not leaked into L2 by default.  For some implementations,
this is controlled via policies as well.  I think that table
could be dual-purposed; meaning, there is no need to create a 
separate table to reflect which routes are being leaked from L1
into L2.

-don

 --- On Wed 10/09, Jeff Parker  wrote:
From: Jeff Parker [mailto: [email-masked]]
To: [email-masked]
     Cc: [email-masked]
Date: Wed, 9 Oct 2002 11:35:00 -0400
Subject: [Isis-wg] RE: Need for isisRedistributeAddrTable

> and covers that case.  See if it has what you need.

------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Wed, 9 Oct 2002 16:13:34 -0400

> separate table to reflect which routes are being leaked from L1
  
Don -
	The description of the Summary Table is in RFC 1195, 
section 3.2.  If it isn't in every implementation, we could 
discuss making it optional.  However, I believ I need to 
provide knobs for everything discussed in an RFCs.  

	You can return to the discussion of the other tables,
but I don't see any choice about including this one.

- jeff parker