Subject: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02

From: "Martin, Christian" <[email-masked]>
Date: Tue, 2 Apr 2002 12:47:20 -0500

Taking it to the WG...

To clarify me earlier post wrt to adding additional information.  When we
originally wrote the draft, we were considering adding 64 byte ACSII
remarks.  Were we all able to have our cake and eat it too, this would be a
good thing.  Tony Li was concerned that adding too much information would
result in wasted LSP space and faster LSP-space exhaustion (with the
corresponding scale-reduction effect).

Hannes, can you clarify the scenario you are presenting?  From a 2547bis
perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC
environment is required.

Thx,
chris

-----Original Message-----
From: stefano previdi [mailto:[email-masked]] 
Sent: Tuesday, April 02, 2002 8:16 AM
To: Hannes Gredler
Cc: Martin, Christian; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02

personally, I have no problems with 64 bits. I just think it's not a 
good idea to make a generic rule just because one particular specific 
case (that can be solved with 32bits anyway).

If the WG is fine with it, I'm fine too.

So, please send your comments to the group.

s.

On Monday 01 April 2002 22:33, Hannes Gredler wrote:
> On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote:
> | On Monday 01 April 2002 10:39, Hannes Gredler wrote:
> | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote:
> | > | On Monday 01 April 2002 02:18, Martin, Christian wrote:
> | > | > Hannes,
> | > | > 
> | > | > Danny McPherson suggested this some time back.  We chose to 
> | > | > stay at 32 bits to be comparable to OSPF tags, but the 
> | > | > addition of a 64 bit tag makes sense.
> | > | 
> | > | it's the redistribution of BGP routes into isis that doesn't 
> | > | make
> | > | a lot of sense to me.
> | > 
> | > stefano,
> | > 
> | > in native v4 routing i'd agree 100%- however there are 
> | > interprovider CoC scenarios where redistributing remote-AS PE 
> | > routers into ISIS/LDP is the only way to get a two-label stack. 
> | > the more scaleable way three-label pushes is not desireable due to 
> | > lack of debugging tools [read: MPLS PING], which two-label 
> | > approaches cleary have;
> | > 
> | > so my client decided to redistribute the few hundred remote-AS PEs 
> | > into IS-IS, which does not do that much harm as the reflect in a 
> | > certain sense "infrastructure" routes;
> | 
> | you don't need 8 bytes for this.
> 
> stefano,
> 
> i am not telling that using 32-bit IDs this is not possible, all i am 
> telling is that tags already assigned via an extended community are 
> _convenient_;
> 
> policy drafts like your one are all about _convenience_
> e.g. route-leaking is done just fine for a couple of years based on 
> access lists - however these are cumbersone to maintain and ultimately 
> you guys have come up with a _convenient_ ways of controlling route 
> leakage -> i.e. tags;
> 
> in multiprovider VPN setups routes are already tagged by extd. 
> communities;
> 
> if i want to get routes across my transit-AS i need
> to setup two policies at the ASBR for each target;
> 
> 1. extd.community->32-bit route-tag and restore it at
>    the second border router
> 
> 2. 32-bit route-tag->extd.community in order to
>    enable "normal" filters based on BGP communities;
> 
> pls note that this procedure need to be done for _every_ route-target;
> 
> ---
> 
> howver for 64-bit tags the AS_wide policy is simple.
> 
> 1. at the first ASBR translate all extd.communities to
>    64-bit tags and
> 2. translate the 64-bit tags back to communities;
> 
> the adv. is here that i need to setup just one policy
> through my AS which stays in place forever; - some sort
> of implicit wildcarding;
> 
> in the 32-bit case i need to setup translation policies
> on _all_ the ASBRs fore _every_ route-target,
> which does not scale administratively;
> 
> ---
> 
> what are you concerned about ? storage space in LSPs ?
> 
> i guess its fair here to trade some scalability of the protocol 
> against convencience.
> 
> 
> /hannes
> 
> 
> 
> 
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 5 Apr 2002 16:22:29 +0200

tx martin for the heads-up;

a customer of mine ran into the following:

inter-AS MPLS VPN, AS2 is the transit AS,
connected by two BGP border routers each
[ASBR12, ASBR21, ASBR22 & ASBR31]

                          AS2(IS-IS)
                            /   \
AS1--ISIS--ASBR12-BGP-ASBR21     ASBR22-BGP-ASBR31--ISIS--AS3

problem: most of the routers in AS1,2,3 do not
run labeled-BGP, and won't run for a while due
to various reasons; -so there is only the IGP
left for delivering the /32s of all the satellite AS
border routers;

idea:

1. leak all VPN PE routers /32 from AS3 into
   BGP-labeled-unicast between ASBR22 and ASBR31
   and tag with a extd. community

2. ASBR22 redistributes (yes i know BGP IGP distribution is
   not a good idea but these are typically not more than 100s
   of routes) into AS2 IS-IS cloud
   and "conserves" the extd. community as 64-bit tag into IS-IS

3. ASBR21 extracts the 64-bit tag and translates it back
   into a extd. community on the BGP session between
   ASBR21 and ASBR12

4. ASBR12 extracts the community and translates it back into 
   IS-IS

---
all the above can be done using 32-bit tags i know - however
it gets complicated as the redistribution policy needs
to get constantly updated [tag allocation etc.] everytime a new
AS is added to the transit cloud [read: ISP aquisitions];

extd.comm->64-bit tag translation policies are very easy to maintain
[configure & forget] and would retain lots of information where the
route came from; sure it eats up LSP space however 
i'd like to ask the WG to think about the scalability vs.
convencience aspect of large tag fields. 

/hannes

On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote:
| Taking it to the WG...
| 
| To clarify me earlier post wrt to adding additional information.  When we
| originally wrote the draft, we were considering adding 64 byte ACSII
| remarks.  Were we all able to have our cake and eat it too, this would be a
| good thing.  Tony Li was concerned that adding too much information would
| result in wasted LSP space and faster LSP-space exhaustion (with the
| corresponding scale-reduction effect).
| 
| Hannes, can you clarify the scenario you are presenting?  From a 2547bis
| perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC
| environment is required.
| 
| Thx,
| chris
| 
| 
|  
| 
| -----Original Message-----
| From: stefano previdi [mailto:[email-masked]] 
| Sent: Tuesday, April 02, 2002 8:16 AM
| To: Hannes Gredler
| Cc: Martin, Christian; [email-masked]; [email-masked];
| [email-masked]; [email-masked]; [email-masked]
| Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02
| 
| 
| 
| personally, I have no problems with 64 bits. I just think it's not a 
| good idea to make a generic rule just because one particular specific 
| case (that can be solved with 32bits anyway).
| 
| If the WG is fine with it, I'm fine too.
| 
| So, please send your comments to the group.
| 
| s.
| 
| 
| 
| On Monday 01 April 2002 22:33, Hannes Gredler wrote:
| > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote:
| > | On Monday 01 April 2002 10:39, Hannes Gredler wrote:
| > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote:
| > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote:
| > | > | > Hannes,
| > | > | > 
| > | > | > Danny McPherson suggested this some time back.  We chose to 
| > | > | > stay at 32 bits to be comparable to OSPF tags, but the 
| > | > | > addition of a 64 bit tag makes sense.
| > | > | 
| > | > | it's the redistribution of BGP routes into isis that doesn't 
| > | > | make
| > | > | a lot of sense to me.
| > | > 
| > | > stefano,
| > | > 
| > | > in native v4 routing i'd agree 100%- however there are 
| > | > interprovider CoC scenarios where redistributing remote-AS PE 
| > | > routers into ISIS/LDP is the only way to get a two-label stack. 
| > | > the more scaleable way three-label pushes is not desireable due to 
| > | > lack of debugging tools [read: MPLS PING], which two-label 
| > | > approaches cleary have;
| > | > 
| > | > so my client decided to redistribute the few hundred remote-AS PEs 
| > | > into IS-IS, which does not do that much harm as the reflect in a 
| > | > certain sense "infrastructure" routes;
| > | 
| > | you don't need 8 bytes for this.
| > 
| > stefano,
| > 
| > i am not telling that using 32-bit IDs this is not possible, all i am 
| > telling is that tags already assigned via an extended community are 
| > _convenient_;
| > 
| > policy drafts like your one are all about _convenience_
| > e.g. route-leaking is done just fine for a couple of years based on 
| > access lists - however these are cumbersone to maintain and ultimately 
| > you guys have come up with a _convenient_ ways of controlling route 
| > leakage -> i.e. tags;
| > 
| > in multiprovider VPN setups routes are already tagged by extd. 
| > communities;
| > 
| > if i want to get routes across my transit-AS i need
| > to setup two policies at the ASBR for each target;
| > 
| > 1. extd.community->32-bit route-tag and restore it at
| >    the second border router
| > 
| > 2. 32-bit route-tag->extd.community in order to
| >    enable "normal" filters based on BGP communities;
| > 
| > pls note that this procedure need to be done for _every_ route-target;
| > 
| > ---
| > 
| > howver for 64-bit tags the AS_wide policy is simple.
| > 
| > 1. at the first ASBR translate all extd.communities to
| >    64-bit tags and
| > 2. translate the 64-bit tags back to communities;
| > 
| > the adv. is here that i need to setup just one policy
| > through my AS which stays in place forever; - some sort
| > of implicit wildcarding;
| > 
| > in the 32-bit case i need to setup translation policies
| > on _all_ the ASBRs fore _every_ route-target,
| > which does not scale administratively;
| > 
| > ---
| > 
| > what are you concerned about ? storage space in LSPs ?
| > 
| > i guess its fair here to trade some scalability of the protocol 
| > against convencience.
| > 
| > 
| > /hannes

---

From: Naiming Shen <[email-masked]>
Date: Tue, 09 Apr 2002 14:41:23 -0700

If one is going to make it a 64-bit tag, it maybe good to make it
a variable size(n x 32bits) to accommodate future "crazy" applications.

 ] tx martin for the heads-up;
 ] 
 ] a customer of mine ran into the following:
 ] 
 ] inter-AS MPLS VPN, AS2 is the transit AS,
 ] connected by two BGP border routers each
 ] [ASBR12, ASBR21, ASBR22 & ASBR31]
 ] 
 ]                           AS2(IS-IS)
 ]                             /   \
 ] AS1--ISIS--ASBR12-BGP-ASBR21     ASBR22-BGP-ASBR31--ISIS--AS3
 ] 
 ] problem: most of the routers in AS1,2,3 do not
 ] run labeled-BGP, and won't run for a while due
 ] to various reasons; -so there is only the IGP
 ] left for delivering the /32s of all the satellite AS
 ] border routers;
 ] 
 ] idea:
 ] 
 ] 1. leak all VPN PE routers /32 from AS3 into
 ]    BGP-labeled-unicast between ASBR22 and ASBR31
 ]    and tag with a extd. community
 ] 
 ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is
 ]    not a good idea but these are typically not more than 100s
 ]    of routes) into AS2 IS-IS cloud
 ]    and "conserves" the extd. community as 64-bit tag into IS-IS
 ] 
 ] 3. ASBR21 extracts the 64-bit tag and translates it back
 ]    into a extd. community on the BGP session between
 ]    ASBR21 and ASBR12
 ] 
 ] 4. ASBR12 extracts the community and translates it back into 
 ]    IS-IS
 ] 
 ] ---
 ] all the above can be done using 32-bit tags i know - however
 ] it gets complicated as the redistribution policy needs
 ] to get constantly updated [tag allocation etc.] everytime a new
 ] AS is added to the transit cloud [read: ISP aquisitions];
 ] 
 ] extd.comm->64-bit tag translation policies are very easy to maintain
 ] [configure & forget] and would retain lots of information where the
 ] route came from; sure it eats up LSP space however 
 ] i'd like to ask the WG to think about the scalability vs.
 ] convencience aspect of large tag fields. 
 ] 
 ] /hannes
 ] 
 ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote:
 ] | Taking it to the WG...
 ] | 
 ] | To clarify me earlier post wrt to adding additional information.  When we
 ] | originally wrote the draft, we were considering adding 64 byte ACSII
 ] | remarks.  Were we all able to have our cake and eat it too, this would be 
a
 ] | good thing.  Tony Li was concerned that adding too much information would
 ] | result in wasted LSP space and faster LSP-space exhaustion (with the
 ] | corresponding scale-reduction effect).
 ] | 
 ] | Hannes, can you clarify the scenario you are presenting?  From a 2547bis
 ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC
 ] | environment is required.
 ] | 
 ] | Thx,
 ] | chris
 ] | 
 ] | 
 ] |  
 ] | 
 ] | -----Original Message-----
 ] | From: stefano previdi [mailto:[email-masked]] 
 ] | Sent: Tuesday, April 02, 2002 8:16 AM
 ] | To: Hannes Gredler
 ] | Cc: Martin, Christian; [email-masked]; [email-masked];
 ] | [email-masked]; [email-masked]; [email-masked]
 ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02
 ] | 
 ] | 
 ] | 
 ] | personally, I have no problems with 64 bits. I just think it's not a 
 ] | good idea to make a generic rule just because one particular specific 
 ] | case (that can be solved with 32bits anyway).
 ] | 
 ] | If the WG is fine with it, I'm fine too.
 ] | 
 ] | So, please send your comments to the group.
 ] | 
 ] | s.
 ] | 
 ] | 
 ] | 
 ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote:
 ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote:
 ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote:
 ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote:
 ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote:
 ] | > | > | > Hannes,
 ] | > | > | > 
 ] | > | > | > Danny McPherson suggested this some time back.  We chose to 
 ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the 
 ] | > | > | > addition of a 64 bit tag makes sense.
 ] | > | > | 
 ] | > | > | it's the redistribution of BGP routes into isis that doesn't 
 ] | > | > | make
 ] | > | > | a lot of sense to me.
 ] | > | > 
 ] | > | > stefano,
 ] | > | > 
 ] | > | > in native v4 routing i'd agree 100%- however there are 
 ] | > | > interprovider CoC scenarios where redistributing remote-AS PE 
 ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. 
 ] | > | > the more scaleable way three-label pushes is not desireable due to 
 ] | > | > lack of debugging tools [read: MPLS PING], which two-label 
 ] | > | > approaches cleary have;
 ] | > | > 
 ] | > | > so my client decided to redistribute the few hundred remote-AS PEs 
 ] | > | > into IS-IS, which does not do that much harm as the reflect in a 
 ] | > | > certain sense "infrastructure" routes;
 ] | > | 
 ] | > | you don't need 8 bytes for this.
 ] | > 
 ] | > stefano,
 ] | > 
 ] | > i am not telling that using 32-bit IDs this is not possible, all i am 
 ] | > telling is that tags already assigned via an extended community are 
 ] | > _convenient_;
 ] | > 
 ] | > policy drafts like your one are all about _convenience_
 ] | > e.g. route-leaking is done just fine for a couple of years based on 
 ] | > access lists - however these are cumbersone to maintain and ultimately 
 ] | > you guys have come up with a _convenient_ ways of controlling route 
 ] | > leakage -> i.e. tags;
 ] | > 
 ] | > in multiprovider VPN setups routes are already tagged by extd. 
 ] | > communities;
 ] | > 
 ] | > if i want to get routes across my transit-AS i need
 ] | > to setup two policies at the ASBR for each target;
 ] | > 
 ] | > 1. extd.community->32-bit route-tag and restore it at
 ] | >    the second border router
 ] | > 
 ] | > 2. 32-bit route-tag->extd.community in order to
 ] | >    enable "normal" filters based on BGP communities;
 ] | > 
 ] | > pls note that this procedure need to be done for _every_ route-target;
 ] | > 
 ] | > ---
 ] | > 
 ] | > howver for 64-bit tags the AS_wide policy is simple.
 ] | > 
 ] | > 1. at the first ASBR translate all extd.communities to
 ] | >    64-bit tags and
 ] | > 2. translate the 64-bit tags back to communities;
 ] | > 
 ] | > the adv. is here that i need to setup just one policy
 ] | > through my AS which stays in place forever; - some sort
 ] | > of implicit wildcarding;
 ] | > 
 ] | > in the 32-bit case i need to setup translation policies
 ] | > on _all_ the ASBRs fore _every_ route-target,
 ] | > which does not scale administratively;
 ] | > 
 ] | > ---
 ] | > 
 ] | > what are you concerned about ? storage space in LSPs ?
 ] | > 
 ] | > i guess its fair here to trade some scalability of the protocol 
 ] | > against convencience.
 ] | > 
 ] | > 
 ] | > /hannes
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list  -  [email-masked]
 ] http://spider.juniper.net/mailman/listinfo/isis-wg

- Naiming

---

From: stefano previdi <[email-masked]>
Date: Wed, 10 Apr 2002 03:02:32 +0200

> a variable size(n x 32bits) to accommodate future "crazy" applications.

after some thoughts and discussions it came out that the best 
way is probably to define one subTLV for 32bits tags and another 
subTLV for 64bits ones. 

s.

---

From: Naiming Shen <[email-masked]>
Date: Tue, 09 Apr 2002 14:41:23 -0700

- Naiming

---

From: stefano previdi <[email-masked]>
Date: Wed, 10 Apr 2002 03:02:32 +0200

s.

---

From: Naiming Shen <[email-masked]>
Date: Tue, 09 Apr 2002 14:41:23 -0700

- Naiming

---

From: stefano previdi <[email-masked]>
Date: Wed, 10 Apr 2002 03:02:32 +0200

s.

---

From: Naiming Shen <[email-masked]>
Date: Tue, 09 Apr 2002 14:41:23 -0700

- Naiming

---

From: stefano previdi <[email-masked]>
Date: Wed, 10 Apr 2002 03:02:32 +0200

s.

---

From: Naiming Shen <[email-masked]>
Date: Tue, 09 Apr 2002 14:41:23 -0700

- Naiming

---

From: stefano previdi <[email-masked]>
Date: Wed, 10 Apr 2002 03:02:32 +0200

s.