Subject: [Isis-wg] thoughts on isis-admin-tags draft

From: Naiming Shen <[email-masked]>
Date: Fri, 27 Sep 2002 23:06:02 -0700

one thing its not clear of the admin-tag operation is that,
when leaking happens in the level boundary, should the admin-tag
by default be removed or rewritten.

i think it would be useful to also define two categories of tags,
(regardless of 4/8 bytes tags). one is to be flooded only 
area wide, the other is for domain wide. the area-wide tagged
routes will not be leaked by default, but the domain-wide tagged
routes will be automatically leaked(either L1->L2 or L2->L1, they
should follow the rule of up/down of course), and the tag MUST
be copied over at the leaking boundary. for the same example
in the draft, if the property A route has a domain-wide tag,
property B has a area-wide tag. Then without any policy needed
at the "border" routers, the 1.1.1.0/24 will be automatically
leaked to every router in the domain and 1.1.2.0/24 will only
stay in the local area. this also get rid of the ambiguity of
if tag should be rewritten during leaking or not.

not only the admin-tag is useful to control the leak operation
between the levels, but many domain-wide applications can use those
tags. it will be very nice users do not need to worry about:
 1) if a route with this tag can be leaked at the level boundaries
 2) if the tag can be rewritten at the level boundaries

for any security concern, local policy should overwrite those
tag rules if needed. this is sort of like bgp's "transitive bit".

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

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 28 Sep 2002 10:55:07 -0700

>tag rules if needed. this is sort of like bgp's "transitive bit".
this is kind of a larger scope issue IMO, namely of a 'flooding scope' 
that connects to the DDRP thread.
We should think whether we want
a per fragment or a 'per-TLV, per-sub-TLV' flooding scope. per TLV would 
be cool _BUT_ it has a serious drawback,
one would need to 'repackage' other people fragments, a no-no, especally 
with authentication, _unless_
we only look at those tags when a TLV is 'reissued' for flooding 
purposes by a 'border-node' [which route
redistribution implies].    Maybe we even want both flooding scopes (I 
personally think that we will have
both hierarchy-defined flooding scopes and kind of 
'transitive'-attribute scopes as you indicate).
Just food for thought.

    -- tony

---

From: Naiming Shen <[email-masked]>
Date: Sat, 28 Sep 2002 12:38:01 -0700

tony,

	yes, this is kind of "scoping". most of the protocols have some
kind of scoping. in ospf, the type 5 LSA; in bgp the "transitive bit" and
"no export" well known community; in multicast there is scoping boundary;
in IPv6(not really routing protocol) the site-locol. admin-tag is probably the
right place to put the scope for isis routing information.
	i would think this is not a fragment/TLV level scoping, but
it's an isis per-prefix scoping. usually for a router there is only
one prefix which need to be flooded over the domain. for isps
do not rewrite ebgp nexthops, they need more. gre source addresses
if not the same as the loopback for bgp, also need to be flooded over.
	since the draft already has a type field of this subtlv,
how about to have type 2 to be domain-wide scoping, and type 1 is
the area scoping subtlv for admin-tag. if its a type-2, it MUST be
flooding(leaked) over the entire domain(still observe the up/down bit),
and the admin-tag value(subtlv) MUST be copied over during the leaking
into another level. local policy can be used to allow all prefixes
leaking, to allow some prefixes leaking, or deny any prefix leaking.
if no policy is applied at the level boundary, then implementations
should follow the admin-tag scoping rule.
	the above is just the "hierarchical scoping" as you mentioned,
for ddrp kind of application, i would think its an isis route
redistribution between two isis instances(probably in level-2
backbone level). yes, the admin-tag can be carried over. but BGP
has the AS paths to detect looping, this does not. unless they want
to add diff admin-tag in each domain to detect the looping;-) then
why not just use bgp? bgp has multi-protocol mechanism already,
i'm sure they are willing to add clns into it...

thanks.

 ] Naiming Shen wrote:
 ] 
 ] >one thing its not clear of the admin-tag operation is that,
 ] >when leaking happens in the level boundary, should the admin-tag
 ] >by default be removed or rewritten.
 ] >
 ] >i think it would be useful to also define two categories of tags,
 ] >(regardless of 4/8 bytes tags). one is to be flooded only 
 ] >area wide, the other is for domain wide. the area-wide tagged
 ] >routes will not be leaked by default, but the domain-wide tagged
 ] >routes will be automatically leaked(either L1->L2 or L2->L1, they
 ] >should follow the rule of up/down of course), and the tag MUST
 ] >be copied over at the leaking boundary. for the same example
 ] >in the draft, if the property A route has a domain-wide tag,
 ] >property B has a area-wide tag. Then without any policy needed
 ] >at the "border" routers, the 1.1.1.0/24 will be automatically
 ] >leaked to every router in the domain and 1.1.2.0/24 will only
 ] >stay in the local area. this also get rid of the ambiguity of
 ] >if tag should be rewritten during leaking or not.
 ] >
 ] >not only the admin-tag is useful to control the leak operation
 ] >between the levels, but many domain-wide applications can use those
 ] >tags. it will be very nice users do not need to worry about:
 ] > 1) if a route with this tag can be leaked at the level boundaries
 ] > 2) if the tag can be rewritten at the level boundaries
 ] >
 ] >for any security concern, local policy should overwrite those
 ] >tag rules if needed. this is sort of like bgp's "transitive bit".
 ] >
 ] this is kind of a larger scope issue IMO, namely of a 'flooding scope' 
 ] that connects to the DDRP thread.
 ] We should think whether we want
 ] a per fragment or a 'per-TLV, per-sub-TLV' flooding scope. per TLV would 
 ] be cool _BUT_ it has a serious drawback,
 ] one would need to 'repackage' other people fragments, a no-no, especally 
 ] with authentication, _unless_
 ] we only look at those tags when a TLV is 'reissued' for flooding 
 ] purposes by a 'border-node' [which route
 ] redistribution implies].    Maybe we even want both flooding scopes (I 
 ] personally think that we will have
 ] both hierarchy-defined flooding scopes and kind of 
 ] 'transitive'-attribute scopes as you indicate).
 ] Just food for thought.
 ] 
 ] 
 ] 
 ]     -- tony
 ] 
 ] 
 ] 

- Naiming