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

From: "Martin, Christian" <[email-masked]>
Date: Sat, 28 Sep 2002 21:35:47 -0400

Tony, Naiming,

Perhaps we should have been more specific with our wording.  The intention
was to make the tag values domain-wide, unless the local policy at the L1/L2
boundary dictates otherwise:

From section 8:

   [...] When IS-IS advertises reachability for some IP
   prefix that has that property, it adds the Administrative Tag to the
   IP reachability information TLV for that prefix, and the tag "sticks"
   to the prefix as it is flooded throughout the routing domian.

Also, from section 6.

   [...] If an implementation needs to
   change tag values, for example, at an area boundary, then the TLV(s)
   SHOULD be copied to the newly generated Level-1 or Level-2 LSP at
   which point, the contents of the SubTLV(s) MAY change as dictated by
   the policy action.

I suppose it depends on where the implementations are at this point,
particularly with regards to the TE extensions implementations.  How are TLV
135 prefixes being treated at the L1/L2 boundary?  AFAIK, they are
regenerated in a new LSP, so the same should apply to the sub-TLVs.

Thoughts?

-chris

> -----Original Message-----
> From: Naiming Shen [mailto:[email-masked]] 
> Sent: Saturday, September 28, 2002 3:38 PM
> To: [email-masked]
> Cc: Naiming Shen; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] thoughts on isis-admin-tags draft 
> 
> 
> 
> 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
> 
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Sat, 28 Sep 2002 19:02:18 -0700

Chris,

 ] Tony, Naiming,
 ] 
 ] Perhaps we should have been more specific with our wording.  The intention
 ] was to make the tag values domain-wide, unless the local policy at the L1/L2
 ] boundary dictates otherwise:
 ] 
 ] >From section 8:
 ] 
 ]    [...] When IS-IS advertises reachability for some IP
 ]    prefix that has that property, it adds the Administrative Tag to the
 ]    IP reachability information TLV for that prefix, and the tag "sticks"
 ]    to the prefix as it is flooded throughout the routing domian.

it needs to add MUST "sticks" here if this is the intention.

 ] 
 ] Also, from section 6.
 ] 
 ]    [...] If an implementation needs to
 ]    change tag values, for example, at an area boundary, then the TLV(s)
 ]    SHOULD be copied to the newly generated Level-1 or Level-2 LSP at
 ]    which point, the contents of the SubTLV(s) MAY change as dictated by
 ]    the policy action.

this is a local policy issue, which is fine.

 ] 
 ] I suppose it depends on where the implementations are at this point,
 ] particularly with regards to the TE extensions implementations.  How are TLV
 ] 135 prefixes being treated at the L1/L2 boundary?  AFAIK, they are
 ] regenerated in a new LSP, so the same should apply to the sub-TLVs.
 ] 
 ] Thoughts?

i think what i ask is not so much about the tag value is kept in
the level transition, but how the PREFIX itself will be flooded
differently due to such a admin-tag is attached.

for most of the implementations i know of, L2->L1 leaking is not
done by default, a configuration with policy needs to be defined
to enable this; but L1->L2 is done automatically. If we can have
the "scope" capability of the admin-tag, then by default without
any policy, the "domain-wide" admin-tagged routes will be flooded
to entire domain by DEFAULT, and "area-wide" admin-tagged routes
will be flooded only within the area by DEFAULT. Even in the
implementation by default, if routes without admin-tag, L1->L2
is leaked and L2->L1 is NOT leaked.

thanks.
 ] 
 ] -chris
 ] 
 ] 
 ] 
 ] > -----Original Message-----
 ] > From: Naiming Shen [mailto:[email-masked]] 
 ] > Sent: Saturday, September 28, 2002 3:38 PM
 ] > To: [email-masked]
 ] > Cc: Naiming Shen; [email-masked]; [email-masked]; 
 ] > [email-masked]; [email-masked]
 ] > Subject: Re: [Isis-wg] thoughts on isis-admin-tags draft 
 ] > 
 ] > 
 ] > 
 ] > 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
 ] > 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming