Subject: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 22 Oct 2013 08:18:02 +0000

Hi All,

We have posted a new draft.

http://datatracker.ietf.org/doc/draft-psarkar-isis-node-admin-tag. 

Please review the draft and provide your feedback and comments.

Thanks
-Pushpasis

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 22 Oct 2013 16:07:15 -0400

Instead of using up a TLV type code, why not make this a Sub-TLV under
the Router Capabilities TLV (#242) and/or MT Capability TLV (#144) or
something like that? (Note that there are currently both 32-bit and
64-bit Administrative Tag Sub-TLVs provided under the MT IP
Reachability and IPv6 IP Reachability (#235 7 #236) TLVs.)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 22 Oct 2013 20:38:14 +0000

Concur.

Why not http://tools.ietf.org/html/rfc5130

Section 2 Says:

"Because path selection is a functional
   set which applies both to TE and non-TE applications the same has not
   added as a new sub-TLV in the Traffic Engingineering TLVs [RFC5305]."

It seems you are concerned for short metrics (TLV 2 and 128 etc..).

Is any body still  deploying short metrics and will those nodes be upgraded to have the specified TLVs?

-- 
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Tuesday, October 22, 2013 1:07 PM
To: Pushpasis Sarkar
Cc: [email-masked]
Subject: Re: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Instead of using up a TLV type code, why not make this a Sub-TLV under the Router Capabilities TLV (#242) and/or MT Capability TLV (#144) or something like that? (Note that there are currently both 32-bit and 64-bit Administrative Tag Sub-TLVs provided under the MT IP Reachability and IPv6 IP Reachability (#235 7 #236) TLVs.)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

> Please review the draft and provide your feedback and comments.
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Qin Wu <[email-masked]>
Date: Wed, 23 Oct 2013 02:02:10 +0000

I share the same concern.
How admin tag is different from one defined in RFC5130 besides different length of the value( one could be either 4 octets or 8 octets while the other MUST be 4 octets)?

It looks admin tag in draft-psarkar-isis-node-admin-tag is used to group nodes in the same  domain while the admin tag in RFC5130 used to associate with some interesting property and control the IP prefix distribution.

Could admin tag in RFC5130 be used to group nodes in the same domain?

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Wednesday, October 23, 2013 4:38 AM
To: Donald Eastlake; Pushpasis Sarkar
Cc: [email-masked]
Subject: Re: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Concur.

Section 2 Says:

-- 
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Tuesday, October 22, 2013 1:07 PM
To: Pushpasis Sarkar
Cc: [email-masked]
Subject: Re: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Thanks,
Donald

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 23 Oct 2013 08:08:00 +0000

> Could admin tag in RFC5130 be used to group nodes in the same domain?

well, I think so.

A node can always be represented by its loopback address which carries 
one or more tags with any sort of semantic (not dictated by the routing 
protocol).

s.

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 23 Oct 2013 10:30:33 +0200

On Tue, Oct 22, 2013 at 08:38:14PM +0000, Uma Chunduri wrote:
| Concur.
| 
| Why not http://tools.ietf.org/html/rfc5130

because prefix-tags, tag *prefixes* and not *nodes*,
 
| Section 2 Says:
| 
| "Because path selection is a functional
|    set which applies both to TE and non-TE applications the same has not
|    added as a new sub-TLV in the Traffic Engingineering TLVs [RFC5305]."
|
| It seems you are concerned for short metrics (TLV 2 and 128 etc..).

short-metrics are rather uninteresting and should be depreceated at some
point. we want to have a node-coloring support which may be used both
for TE (C-SPF constraints) and non-TE (R-LFA, managability)
applications.
 
| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
| Sent: Tuesday, October 22, 2013 1:07 PM
| To: Pushpasis Sarkar
| Cc: [email-masked]
| Subject: Re: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00
| 
| Instead of using up a TLV type code, why not make this a Sub-TLV under the Router Capabilities TLV (#242) and/or MT Capability TLV (#144) or something like that? (Note that there are currently both 32-bit and 64-bit Administrative Tag Sub-TLVs provided under the MT IP Reachability and IPv6 IP Reachability (#235 7 #236) TLVs.)
| 
| Thanks,
| Donald
| =============================
|  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
|  155 Beaver Street, Milford, MA 01757 USA  [email-masked]
| 
| 
| On Tue, Oct 22, 2013 at 4:18 AM, Pushpasis Sarkar <[email-masked]> wrote:
| > Hi All,
| >
| > We have posted a new draft.
| >
| > http://datatracker.ietf.org/doc/draft-psarkar-isis-node-admin-tag.
| >
| > Please review the draft and provide your feedback and comments.
| >
| > Thanks
| > -Pushpasis
| _______________________________________________
| Isis-wg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/isis-wg
| _______________________________________________
| Isis-wg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/isis-wg
| 
|

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 23 Oct 2013 10:43:16 +0200

On Wed, Oct 23, 2013 at 08:08:00AM +0000, Stefano Previdi (sprevidi) wrote:
| > Could admin tag in RFC5130 be used to group nodes in the same domain?
| 
| well, I think so.
| 
| A node can always be represented by its loopback address which carries 
| one or more tags with any sort of semantic (not dictated by the routing 
| protocol).

in the most simple case (single loopback address, TE router-ID ==  loopback prefix)
prefix-admin-tags MAY be used to identify a node.

it starts getting a bit hairy when any of the above assumption is not true
(e.g. multiple loopback addresses or e.g. empty intersection of TE router-ID to
the prefixes that a node originates). - which prefix represents then
the 'node-identity' ?

for link-colors we have a dedicated link-specific extension
(following your logic one could argue that we do not need that,
as in theory one could add prefix-tags to IP-subnets ;-) ) -
therefore we're asking now for dedicated node-colors,
(and not some heuristics bolted on top of IP prefixes tagging).

/hannes

---

From: <[email-masked]>
Date: Wed, 23 Oct 2013 09:02:58 +0000

>From: Qin Wu >Sent: Wednesday, October 23, 2013 4:02 AM
>
>How admin tag is different from one defined in RFC5130 besides different
>length of the value( one could be either 4 octets or 8 octets while the
>other MUST be 4 octets)?
>
>It looks admin tag in draft-psarkar-isis-node-admin-tag is used to group
>nodes in the same  domain while the admin tag in RFC5130 used to associate
>with some interesting property and control the IP prefix distribution.
>

This gets complicated for L1/L2 ABR which redistributes prefixes between areas. In such case, I guess that in theory you could filter out, during redistribution, the prefix tags which are overloaded with node tags but updating the filter over the time is error prone.

Regards,
Bruno

>Instead of using up a TLV type code, why not make this a Sub-TLV under the
>Router Capabilities TLV (#242) and/or MT Capability TLV (#144) or something
>like that? (Note that there are currently both 32-bit and 64-bit
>Administrative Tag Sub-TLVs provided under the MT IP Reachability and IPv6
>IP Reachability (#235 7 #236) TLVs.)
>
>Thanks,
>Donald

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Qin Wu <[email-masked]>
Date: Wed, 23 Oct 2013 10:42:25 +0000

I see your point.
One more followup question is:
I am wondering how node tag is generated? How node tag generation is different from prefix tag generation?

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 5:03 PM
To: Qin Wu
Cc: [email-masked]; Pushpasis Sarkar
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Regards,
Bruno

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 23 Oct 2013 14:00:32 +0000

On Wed, Oct 23, 2013 at 08:08:00AM +0000, Stefano Previdi (sprevidi) wrote:
| > Could admin tag in RFC5130 be used to group nodes in the same domain?
| 
| well, I think so.
| 
| A node can always be represented by its loopback address which carries 
| one or more tags with any sort of semantic (not dictated by the 
| routing protocol).

in the most simple case (single loopback address, TE router-ID ==  loopback prefix) prefix-admin-tags MAY be used to identify a node.

it starts getting a bit hairy when any of the above assumption is not true (e.g. multiple loopback addresses or e.g. empty intersection of TE router-ID to the prefixes that a node originates). - which prefix represents then the 'node-identity' ?

[Uma]: TRUE. 
      ..even worse with redistribution/leaking and with a possible multi-homing it's difficult to know this 'node-identity' deterministically

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 23 Oct 2013 14:04:03 +0000

>      ..even worse with redistribution/leaking and with a possible multi-homing it's difficult to know this 'node-identity' deterministically

naively, when 64-bits tags have been introduced, I thought the idea 
was to carry exactly that kind of semantic.

s.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 23 Oct 2013 14:10:44 +0000

>> we want to have a node-coloring support which may be used both for TE (C-SPF constraints) 
>> and non-TE (R-LFA, managability) applications.

[Uma]: I see your point and agree the need for a node admin tag. You mentioned 2 cases R-LFA, 
       manageability.

       But, step back a bit -

       1. Node coloring (resource class) for TE is sub-tlv 3 of TLV 22(5305). 
          You just want simple admin tags for the node for manageability 
          (http://tools.ietf.org/html/draft-litkowski-rtgwg-lfa-manageability-01) 
          in non-TE cases.
          Why to burn a separate TLV? Do you see a reason for not using undefined 
          sub-tlv 1 & 2 in TLV 22(5305)/TLV222. Essentially this could be similar to 
          prefix admin tags.

       2. I don't think this draft addresses the R-LFA  concern to deterministically 
          identify PQ node IP address for T-LDP session 
          IMO, To fully address this, a "reachable node identifier" prefix needs to be advertised
          and this can be effectively used to establish T-LDP session (not for adding it to rib/fib).
          This also can be specified in TLV 22, unused sub-tlv 1 & 2 along with the node tag(s).

       Summary:
       Use TLV-22's (or 222's) undefined sub TLVs 1,2 and add a "reachable node identifier" to address both concerns in one-shot.
 
-- 
Uma C.

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 23 Oct 2013 17:31:46 +0200

On Wed, Oct 23, 2013 at 02:04:03PM +0000, Stefano Previdi (sprevidi) wrote:
| 
| On Oct 23, 2013, at 4:00 PM, Uma Chunduri wrote:
| 
| > On Wed, Oct 23, 2013 at 08:08:00AM +0000, Stefano Previdi (sprevidi) wrote:
| > | > Could admin tag in RFC5130 be used to group nodes in the same domain?
| > | 
| > | well, I think so.
| > | 
| > | A node can always be represented by its loopback address which carries 
| > | one or more tags with any sort of semantic (not dictated by the 
| > | routing protocol).
| > 
| > in the most simple case (single loopback address, TE router-ID ==  loopback prefix) prefix-admin-tags MAY be used to identify a node.
| > 
| > it starts getting a bit hairy when any of the above assumption is not true (e.g. multiple loopback addresses or e.g. empty intersection of TE router-ID to the prefixes that a node originates). - which prefix represents then the 'node-identity' ?
| > 
| > [Uma]: TRUE. 
| >      ..even worse with redistribution/leaking and with a possible multi-homing it's difficult to know this 'node-identity' deterministically
| 
| 
| naively, when 64-bits tags have been introduced, I thought the idea 
| was to carry exactly that kind of semantic.

afaik - the 64-bit tags actually have been introduced to 'share'
markers between BGP extended community space and IGP tag space.
see http://www.ietf.org/mail-archive/web/isis-wg/old-archive/2002-April/002119.html

/hannes

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 23 Oct 2013 15:38:39 +0000

> see http://www.ietf.org/mail-archive/web/isis-wg/old-archive/2002-April/002119.html

sure but not limited to...

s.

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 23 Oct 2013 17:43:07 +0200

> sure but not limited to...

it was stupid idea, anyway :-/

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 23 Oct 2013 16:09:44 +0000

Hi Uma,

We have discussed this over and over internally. And we found strong motivations for not putting it in the TE-TLVs due to the following reasons.

- During discussing [draft-ietf-rtgwg-lfa-manageability-01] implementation in ISIS we have found a lot of the parameters to be considered for alternate path selection comes from TE-TLVs. In absence of TE (considering nodes that do not participate in TEs) the number of parameters left for evaluation is very few. Also for cases where we want to just consider paths based on the nodes that it includes there is no reason we should consider that all nodes in the backup enable TE. We just need to identify the groups the nodes belong to. 
- Though backup path selection(where most of the evaluation criteria are derived from TE attributes) is the major motivation for this per-node admin tag, we really don't want to restrict the application to backup-path-selection. It can be any application where we need consider the nodes that are involved in the scenario. E.g. we can have a new route-filter policy attribute that can select/de-select prefixes originated in local domain by two separate originators(possible ABRs or L2 routers) with same cost and prefer installing a primary path via only one. 

As for the RLFA T-LDP session identifier, perhaps we need a separate solution. But I acknowledge the need of a solution there too :)

Thanks
-Pushpasis

-----Original Message-----
From: Uma Chunduri [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 7:41 PM
To: Hannes Gredler
Cc: Donald Eastlake; Pushpasis Sarkar; [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

>> we want to have a node-coloring support which may be used both for TE 
>> (C-SPF constraints) and non-TE (R-LFA, managability) applications.

       But, step back a bit -

       Summary:
 
--
Uma C.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 23 Oct 2013 17:10:10 +0000

> it was stupid idea, anyway :-/

Well, I won't tell the author of the proposal... I promised ;-)

Anyway, I still don't see why you don't want to use tags. You can 
use them in order to specify that:
. a prefix represents the node
. a prefix represents the characteristics of the node
and you can do both within the same tag.

s.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 23 Oct 2013 18:14:12 +0000

Hannes -

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hannes Gredler
> Sent: Wednesday, October 23, 2013 1:43 AM
> To: Stefano Previdi (sprevidi)

It would be easier to judge the appropriateness of the chosen encoding if you could clarify the "multiple loopback" use case. Does this apply to RLFA manageability or some other use? Is there a need to associate a given loopback address with a given node-color? 

As currently defined it would be impossible to leak the node information - is that limitation intentional? 

(BTW, I don't worry too much about the "empty intersection" case. While theoretically possible it would likely render the router ID useless - which means it is simply a misconfiguration.)

Thanx.

   Les

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 23 Oct 2013 20:28:04 +0000

>>>>> (e.g. multiple loopback addresses or e.g. empty intersection of TE router-ID 
>>>>> to the prefixes that a node originates). - which prefix represents then the 'node-identity' ?

	>>Anyway, I still don't see why you don't want to use tags. You can use them in order to specify that:
	>> . a prefix represents the characteristics of the node and you can do both within the same tag.

[Uma]: ..................Probably Hannes might have a different answer....................................
       FWIW -
       Prefix admin tags in RFC 5130 is very interesting as well as useful document; and it all depends on how 
       the operator can effectively use this to do multiple different things.  But, I don't think overloading 
       this to identify a node is good (or works all the time). Again it depends on what all we want to do with this.

       Let's limit the discussion to multiple loopback case only for now -
       1. If we just want to tag a group of nodes for lfa manageability (not for r-lfa), probably you can stick to
          any of the loopback, probably as specified per the policy.     
              - You have no idea which 135, you will have this (and changes there after) as a receiver
              - you can create a nightmare as leaking is allowed for these (per 5130 it's no MUST that one 
                has to remove the tags  while leaking)  
       2. On the other hand if this is used for RLFA (this is not mentioned in the draft though), the question 
          above stands "which prefix represents then the 'node-identity'"?
             - I don't think operator should be involved at all here to indicate, one deterministically reachable prefix
               to represent the node..(it should be natural..)
       Hence, I don't think using prefix-admin tag is the right approach to identify the node.
 
-- 
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 23 Oct 2013 20:34:28 +0000

Pushpasis -

Though I feel it's useful to have admin tag capability for the node (instead of 
dealing with all 135's i.e., leaked, redistributed, multiple loopbacks etc..); 
IMO, we need not bring TE discussion at all when coming-up with a solution. 

Though, it seems it is too early to discuss on the solution, see my quick replies in-line [Uma] any ways.

-- 
Uma C. 

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 9:10 AM
To: Uma Chunduri; Hannes Gredler
Cc: Donald Eastlake; [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Hi Uma,

- During discussing [draft-ietf-rtgwg-lfa-manageability-01] implementation in ISIS we have found a lot of the parameters to be considered for alternate path selection comes from TE-TLVs. In absence of TE (considering nodes that do not participate in TEs) the number of parameters left for evaluation is very few. Also for cases where we want to just consider paths based on the nodes that it includes there is no reason we should consider that all nodes in the backup enable TE. 
We just need to identify the groups the nodes belong to. 

[Uma]: As I said regardless of node participates in TE; you didn't answer why we need separate TLV? 

- Though backup path selection(where most of the evaluation criteria are derived from TE attributes) is the major motivation for this per-node admin tag, we really don't want to restrict the application to backup-path-selection. 

[Uma]: Generic is fine but why new TLV?

It can be any application where we need consider the nodes that are involved in the scenario. E.g. we can have a new route-filter policy attribute that can select/de-select prefixes originated in local domain by two separate originators(possible ABRs or L2 routers) with same cost and prefer installing a primary path via only one. 

[Uma]: Perhaps..

Thanks
-Pushpasis

-----Original Message-----
From: Uma Chunduri [mailto:[email-masked]]
Sent: Wednesday, October 23, 2013 7:41 PM
To: Hannes Gredler
Cc: Donald Eastlake; Pushpasis Sarkar; [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

       But, step back a bit -

       Summary:
 
--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 23 Oct 2013 21:06:26 +0000

Uma -

The question of "which prefix represents the 'node-identity'" has been actively discussed for over a year - mainly in the context of RLFA. For some of us the answer is intuitive - it's the router ID. For others, the answer is not so intuitive. My recollection was that there was an agreement between the two sides that we needed to write a short draft explicitly stating:

1)Node ID == Router ID
2)In the case where there is no Router ID define a tie breaking rule (e.g. highest advertised /32)

That draft was never written.

The current draft does nothing to resolve this issue.

   Les

> Uma Chunduri
> Sent: Wednesday, October 23, 2013 1:28 PM
> To: Stefano Previdi (sprevidi); Hannes Gredler
> [Uma]: ..................Probably Hannes might have a different
> answer....................................
>        FWIW -
>        this to identify a node is good (or works all the time). Again it
> depends on what all we want to do with this.
> 
>              - I don't think operator should be involved at all here to
> indicate, one deterministically reachable prefix

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 24 Oct 2013 06:51:25 +0000

[Uma]: As I said regardless of node participates in TE; you didn't answer why we need separate TLV? 
 [Uma]: Generic is fine but why new TLV?
[Pushpasis] Like already said, we cannot add it to any of the RFC5305 TE-TLVs because none were found to be appropriate. Firstly we don't want to associate this with TE. And secondly there are not TE TLVs currently that represents a router. The TE Router-ID TLV does not represents a router sufficiently. Many in this workgroup has suggested for adding it as a sub-TLV in router-capability TLV. We are currently trying to reason out the pros and cons of that approach. 
There is a similar draft in OSPF working group[http://tools.ietf.org/html/draft-hegde-ospf-node-admin-tag-00], where a TLV has been added in RI-LSA. Folks has been asking to carve it as a separate LSA while we think again RI-LSA is the most appropriate place for this.

-----Original Message-----
From: Uma Chunduri [mailto:[email-masked]] 
Sent: Thursday, October 24, 2013 2:04 AM
To: Pushpasis Sarkar; Hannes Gredler
Cc: Donald Eastlake; [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Pushpasis -

Though I feel it's useful to have admin tag capability for the node (instead of dealing with all 135's i.e., leaked, redistributed, multiple loopbacks etc..); IMO, we need not bring TE discussion at all when coming-up with a solution. 

--
Uma C. 

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 9:10 AM
To: Uma Chunduri; Hannes Gredler
Cc: Donald Eastlake; [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Hi Uma,

[Uma]: Perhaps..

Thanks
-Pushpasis

-----Original Message-----
From: Uma Chunduri [mailto:[email-masked]]
Sent: Wednesday, October 23, 2013 7:41 PM
To: Hannes Gredler
Cc: Donald Eastlake; Pushpasis Sarkar; [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

       But, step back a bit -

       Summary:
 
--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 29 Oct 2013 05:52:22 +0000

Les,

We are discussing a different thing in the context of the draft mentioned in the subject.
Let me respond any ways -

In-line [Uma]: 

-- 
Uma C. 

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 2:06 PM
To: Uma Chunduri; Stefano Previdi (sprevidi); Hannes Gredler
Cc: [email-masked]; Pushpasis Sarkar
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Uma -

1)Node ID == Router ID

[Uma]: Highest advertised /32 still can't guarantee any thing and you still don't know if the node 
       indeed hosted this IP.
       Probably, if there is no Router ID, you can't do much today other than enable them to 
       advertise one (by mandating 134 regardless of TE). 

That draft was never written.
[Uma]: It's good to have 134 always representing the nodes' loopback IP.

The current draft does nothing to resolve this issue.
[Uma]: That's what exactly I said below.

   Les

> Subject: Re: [Isis-wg] Soliciting feedback and comments on 
> draft-psarkar- isis-node-admin-tag-00
> 
> >>>>> it starts getting a bit hairy when any of the above assumption 
> >>>>> is not
> true
> >>>>> (e.g. multiple loopback addresses or e.g. empty intersection of 
> >>>>> TE
> router-ID
> >>>>> to the prefixes that a node originates). - which prefix 
> >>>>> represents then
> the 'node-identity' ?
> 
>        Prefix admin tags in RFC 5130 is very interesting as well as 
> useful document; and it all depends on how
>        this to identify a node is good (or works all the time). Again 
> it depends on what all we want to do with this.
> 
>        1. If we just want to tag a group of nodes for lfa 
> manageability (not for r-lfa), probably you can stick to
>        2. On the other hand if this is used for RLFA (this is not 
> mentioned in the draft though), the question
>              - I don't think operator should be involved at all here 
> to indicate, one deterministically reachable prefix

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 29 Oct 2013 06:40:13 +0000

Les/Uma,

Logically admin tag and router-ids are different. The admin tag represents a group to which the router belongs. The router may belong to multiple groups and hence originate multiple admin tags. However, technically a router should have only unique router-id. Though RFC5305 did not put a restriction and any router   more than one router-id. Still, the router-id is conceptually different and we did not want to solve the confusion with router-id and node-tag in this draft. We just wanted a separate approach for the router to be able to tell which all groups it belongs to. In our opinion this is simpler and may have many uses going forward in future.

For the case of deriving the admin tag by considering the tag associated with a prefix in Prefix TLV which is also published in the Rtr-Id TLV, here is my thoughts.. Typically prefix tags are configured under interface config or assigned by route redistribution policies. If we choose the same tag as the node-admin tag, the node-admin tag may un-intentionally change, when the user configures a different tag under interface config or chooses a different route-policy. So, the user need to be extra careful in doing so. Such complexities should be avoided. 

Thanks
-Pushpasis

-----Original Message-----
From: Uma Chunduri [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 11:22 AM
To: Les Ginsberg (ginsberg); Stefano Previdi (sprevidi); Hannes Gredler
Cc: [email-masked]; Pushpasis Sarkar
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Les,

In-line [Uma]: 

-- 
Uma C. 

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 2:06 PM
To: Uma Chunduri; Stefano Previdi (sprevidi); Hannes Gredler
Cc: [email-masked]; Pushpasis Sarkar
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Uma -

1)Node ID == Router ID

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 29 Oct 2013 07:01:31 +0000

Pushpasis -

It is likely that Uma and I have introduced a sub-thread into this discussion without changing the subject line and thereby caused some confusion. Apologies for that.

The sub-thread Uma and I had was on the question ""which prefix represents the 'node-identity'" - on which I think Uma and I agree that should be TLV 134 (or TLV 140 for IPv6). Further discussion on that should probably move to a different subject line.

I have never suggested that what you had in mind in the draft was a new form of "router-id". I would, however, appreciate clarification on the "multiple loopback" case and its relationship to your draft. Please look at my earlier email (addressed to Hannes) in which I posed some questions which have yet to be answered.

Thanx.

   Les

> Sent: Monday, October 28, 2013 11:40 PM
> To: Uma Chunduri; Les Ginsberg (ginsberg); Stefano Previdi (sprevidi); Hannes
> Gredler
> Cc: [email-masked]
> Logically admin tag and router-ids are different. The admin tag represents a
> group to which the router belongs. The router may belong to multiple groups
> and hence originate multiple admin tags. However, technically a router should
> have only unique router-id. Though RFC5305 did not put a restriction and any
> router   more than one router-id. Still, the router-id is conceptually
> different and we did not want to solve the confusion with router-id and node-
> tag in this draft. We just wanted a separate approach for the router to be
> able to tell which all groups it belongs to. In our opinion this is simpler
> and may have many uses going forward in future.
> 
> For the case of deriving the admin tag by considering the tag associated with
> a prefix in Prefix TLV which is also published in the Rtr-Id TLV, here is my
> thoughts.. Typically prefix tags are configured under interface config or
> assigned by route redistribution policies. If we choose the same tag as the
> node-admin tag, the node-admin tag may un-intentionally change, when the user
> configures a different tag under interface config or chooses a different
> route-policy. So, the user need to be extra careful in doing so. Such
> complexities should be avoided.
> 
> Thanks
> -Pushpasis
> 
> The question of "which prefix represents the 'node-identity'" has been
> actively discussed for over a year - mainly in the context of RLFA. For some
> of us the answer is intuitive - it's the router ID. For others, the answer is
> not so intuitive. My recollection was that there was an agreement between the
> two sides that we needed to write a short draft explicitly stating:
> 
> 1)Node ID == Router ID
> >        the operator can effectively use this to do multiple different
> things.
> > But, I don't think overloading

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 29 Oct 2013 08:27:32 +0000

[Les] It would be easier to judge the appropriateness of the chosen encoding if you could clarify the "multiple loopback" use case. Does this apply to RLFA manageability or some other use? Is there a need to associate a given loopback address with a given node-color? 
[Pushpasis] I don't see why RLFA will need multiple loopbacks. However RFC 5305 does not restrict a router from originating multiple router-ids. So in case a router is configured with multiple loopbacks certain implementations can originate one TE-router-id TLV per loopback address. For LFA manageability(leaving aside RLFA) there is a need to tag or associate a router with one or more groups of nodes, and then engineer backup paths based on the groups the router/nodes on the backup path belongs to. The way we can currently do that is by associating a tag with the prefix that is also the router-id. So a receiving router will pull the router-id from rtr-id tlv, find a matching prefix in the ip-prefix tlv and then pick the prefix-tag associated with it, and associate the prefix-tag with the originating router. However if a router really originates multiple rtr-ids(there seems to be some possibility), which one(s) should it consider? Should it consider all? Like mentioned in the previous mail on this thread, having pick node tags/colors from prefix tags can add complexity for the operator.

[Les] As currently defined it would be impossible to leak the node information - is that limitation intentional? 
[Pushpasis] Don't see a need of leaking the node-admin tag if the node itself is not visible across levels. Whatever be the use of node-admin tag be, it will always need a node to be associated with. 

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 11:44 PM
To: Hannes Gredler; Stefano Previdi (sprevidi)
Cc: [email-masked]; Pushpasis Sarkar
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Hannes -

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hannes Gredler
> | A node can always be represented by its loopback address which 
> | carries one or more tags with any sort of semantic (not dictated by 
> | the routing protocol).
> 
> in the most simple case (single loopback address, TE router-ID ==  
> loopback
> prefix)
> it starts getting a bit hairy when any of the above assumption is not 
> true (e.g. multiple loopback addresses or e.g. empty intersection of 
> TE router-ID to the prefixes that a node originates). - which prefix 
> represents then the 'node-identity' ?

Thanx.

   Les

> 
> for link-colors we have a dedicated link-specific extension (following 
> your logic one could argue that we do not need that, as in theory one 
> could add prefix-tags to IP-subnets ;-) ) - therefore we're asking now 
> for dedicated node-colors, (and not some heuristics bolted on top of 
> IP prefixes tagging).
> 
> /hannes
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 29 Oct 2013 14:00:15 +0000

Pushpasis -

I am not trying to insert "router-id" into the discussion (that was an aside between Uma and myself). I am trying to understand what your draft is intended to do. Hannes mentioned below that "multiple loopbacks" was one of the scenarios where additional support was needed and in part motivated this draft. I am therefore asking how the extensions defined in your draft are used in the case of multiple loopbacks.

Thanx.

   Les
 
> Sent: Tuesday, October 29, 2013 1:28 AM
> To: Les Ginsberg (ginsberg); Hannes Gredler; Stefano Previdi (sprevidi)
> Cc: [email-masked]
> [Les] It would be easier to judge the appropriateness of the chosen encoding
> if you could clarify the "multiple loopback" use case. Does this apply to
> RLFA manageability or some other use? Is there a need to associate a given
> loopback address with a given node-color?
> [Pushpasis] I don't see why RLFA will need multiple loopbacks. However RFC
> 5305 does not restrict a router from originating multiple router-ids. So in
> case a router is configured with multiple loopbacks certain implementations
> can originate one TE-router-id TLV per loopback address. For LFA
> manageability(leaving aside RLFA) there is a need to tag or associate a
> router with one or more groups of nodes, and then engineer backup paths based
> on the groups the router/nodes on the backup path belongs to. The way we can
> currently do that is by associating a tag with the prefix that is also the
> router-id. So a receiving router will pull the router-id from rtr-id tlv,
> find a matching prefix in the ip-prefix tlv and then pick the prefix-tag
> associated with it, and associate the prefix-tag with the originating router.
> However if a router really originates multiple rtr-ids(there seems to be some
> possibility), which one(s) should it consider? Should it consider all? Like
> mentioned in the previous mail on this thread, having pick node tags/colors
> from prefix tags can add complexity for the operator.
> 
> [Les] As currently defined it would be impossible to leak the node
> information - is that limitation intentional?
> [Pushpasis] Don't see a need of leaking the node-admin tag if the node itself
> is not visible across levels. Whatever be the use of node-admin tag be, it
> will always need a node to be associated with.
> 
> It would be easier to judge the appropriateness of the chosen encoding if you
> could clarify the "multiple loopback" use case. Does this apply to RLFA
> manageability or some other use? Is there a need to associate a given
> loopback address with a given node-color?
> 
> (BTW, I don't worry too much about the "empty intersection" case. While
> theoretically possible it would likely render the router ID useless - which
> means it is simply a misconfiguration.)
> 
> Thanx.
> 
>    Les
> 
> >

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 29 Oct 2013 14:39:45 +0000

Hi Les,

In our draft, we are proposing that user should be able to configure one or more admin tags on the router (not on any loopback interfaces on it). We are decoupling it from loopbacks or any other types of interfaces attached. All the configured node-admin tags will be carried in the new TLV proposed. For the sake of lfa-manageability applications, on the PLR, these will be collected and stored in the list of backup path attributes for any backup path that traverses the originating router(i.e. the router that originated the node-admin tags). Irrespective of whether the originating router has one or multiple loopbacks, the LSP originated by the router will have only that many admin-tag that was configured by the operator on the router.

Thanks
-Pushpasis

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 7:30 PM
To: Pushpasis Sarkar; Hannes Gredler; Stefano Previdi (sprevidi)
Cc: [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Pushpasis -

Thanx.

   Les
 
> Subject: RE: [Isis-wg] Soliciting feedback and comments on 
> draft-psarkar-
> isis-node-admin-tag-00
> 
> [Les] It would be easier to judge the appropriateness of the chosen 
> encoding if you could clarify the "multiple loopback" use case. Does 
> this apply to RLFA manageability or some other use? Is there a need to 
> associate a given loopback address with a given node-color?
> 5305 does not restrict a router from originating multiple router-ids. 
> So in case a router is configured with multiple loopbacks certain 
> implementations can originate one TE-router-id TLV per loopback 
> address. For LFA manageability(leaving aside RLFA) there is a need to 
> tag or associate a router with one or more groups of nodes, and then 
> engineer backup paths based on the groups the router/nodes on the 
> backup path belongs to. The way we can currently do that is by 
> associating a tag with the prefix that is also the router-id. So a 
> receiving router will pull the router-id from rtr-id tlv, find a 
> matching prefix in the ip-prefix tlv and then pick the prefix-tag associated with it, and associate the prefix-tag with the originating router.
> However if a router really originates multiple rtr-ids(there seems to 
> be some possibility), which one(s) should it consider? Should it 
> consider all? Like mentioned in the previous mail on this thread, 
> having pick node tags/colors from prefix tags can add complexity for the operator.
> 
> [Pushpasis] Don't see a need of leaking the node-admin tag if the node 
> itself is not visible across levels. Whatever be the use of node-admin 
> tag be, it will always need a node to be associated with.
> 
> Subject: RE: [Isis-wg] Soliciting feedback and comments on 
> draft-psarkar-
> isis-node-admin-tag-00
> 
> Hannes -
> 
> > | carries one or more tags with any sort of semantic (not dictated 
> > | by the routing protocol).
> >
> > it starts getting a bit hairy when any of the above assumption is 
> > not true (e.g. multiple loopback addresses or e.g. empty 
> > intersection of TE router-ID to the prefixes that a node 
> > originates). - which prefix represents then the 'node-identity' ?
> 
> It would be easier to judge the appropriateness of the chosen encoding 
> if you could clarify the "multiple loopback" use case. Does this apply 
> to RLFA manageability or some other use? Is there a need to associate 
> a given loopback address with a given node-color?
> 
> As currently defined it would be impossible to leak the node 
> (BTW, I don't worry too much about the "empty intersection" case. 
> While theoretically possible it would likely render the router ID 
> useless - which means it is simply a misconfiguration.)
> 
> Thanx.
> 
>    Les
> 
> >
> > (following your logic one could argue that we do not need that, as 
> > in theory one could add prefix-tags to IP-subnets ;-) ) - therefore 
> > we're asking now for dedicated node-colors, (and not some heuristics 
> > bolted on top of IP prefixes tagging).
> >
> > /hannes
> >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 29 Oct 2013 19:48:09 +0000

Pushpasis -

OK - so it seems the multiple loopback reference is not relevant. You simply want to be able to have a node identify how many admin groups it supports - which makes me wonder - as others commented early on - why a sub-TLV in the Router Capability TLV is not more appropriate? It seems to have exactly the characteristics you desire:

1)Unambiguously identifies the node doing the advertising
2)Provides control of leaking (you don't want it - you can specify that - but if you find a need for it later it is available)

Also, it would seem that the admin groups could be defined as a variable length bit mask allowing more efficient encoding - and clearly differentiating them from the admin tags already defined for use with prefix reachability advertisements.

Does this align with your intended use cases?

   Les

> Sent: Tuesday, October 29, 2013 7:40 AM
> In our draft, we are proposing that user should be able to configure one or
> more admin tags on the router (not on any loopback interfaces on it). We are
> decoupling it from loopbacks or any other types of interfaces attached. All
> the configured node-admin tags will be carried in the new TLV proposed. For
> the sake of lfa-manageability applications, on the PLR, these will be
> collected and stored in the list of backup path attributes for any backup
> path that traverses the originating router(i.e. the router that originated
> the node-admin tags). Irrespective of whether the originating router has one
> or multiple loopbacks, the LSP originated by the router will have only that
> many admin-tag that was configured by the operator on the router.
> 
> Thanks
> -Pushpasis
> 
> I am not trying to insert "router-id" into the discussion (that was an aside
> between Uma and myself). I am trying to understand what your draft is
> intended to do. Hannes mentioned below that "multiple loopbacks" was one of
> the scenarios where additional support was needed and in part motivated this
> draft. I am therefore asking how the extensions defined in your draft are
> used in the case of multiple loopbacks.
> 
> Thanx.
> 
>    Les
> 
> > matching prefix in the ip-prefix tlv and then pick the prefix-tag

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 30 Oct 2013 09:06:14 +0000

Les,

Yes we are also considering it as a sub-TLV under Router-capability. But we are yet to consider the pros and cons of the same. 

As for the case of using a variable length bitmap,  currently we want the node-admin tag to follow the same notion as route/prefix tag (or SRLG) and not link colors/admin groups, with value range of (1 to 2^32-1) and carry only the ones that are configured on the router. Going the bitmap way we will have to restrict the values to a much lower range or carry all the unnecessary bits in the TLV even if a tag value has not been configured on the router. We would not like to add these restrictions thinking of future applicability. 

Thanks
-Pushpasis

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 1:18 AM
To: Pushpasis Sarkar; Hannes Gredler; Stefano Previdi (sprevidi)
Cc: [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Pushpasis -

1)Unambiguously identifies the node doing the advertising 2)Provides control of leaking (you don't want it - you can specify that - but if you find a need for it later it is available)

   Les

> In our draft, we are proposing that user should be able to configure 
> one or more admin tags on the router (not on any loopback interfaces 
> on it). We are decoupling it from loopbacks or any other types of 
> interfaces attached. All the configured node-admin tags will be 
> carried in the new TLV proposed. For the sake of lfa-manageability 
> applications, on the PLR, these will be collected and stored in the 
> list of backup path attributes for any backup path that traverses the 
> originating router(i.e. the router that originated the node-admin 
> tags). Irrespective of whether the originating router has one or 
> multiple loopbacks, the LSP originated by the router will have only that many admin-tag that was configured by the operator on the router.
> 
> Thanks
> -Pushpasis
> 
> I am not trying to insert "router-id" into the discussion (that was an 
> aside between Uma and myself). I am trying to understand what your 
> draft is intended to do. Hannes mentioned below that "multiple 
> loopbacks" was one of the scenarios where additional support was 
> needed and in part motivated this draft. I am therefore asking how the 
> extensions defined in your draft are used in the case of multiple loopbacks.
> 
> Thanx.
> 
>    Les
> 
> > this apply to RLFA manageability or some other use? Is there a need 
> > to associate a given loopback address with a given node-color?
> > address. For LFA manageability(leaving aside RLFA) there is a need 
> > to tag or associate a router with one or more groups of nodes, and 
> > then engineer backup paths based on the groups the router/nodes on 
> > the backup path belongs to. The way we can currently do that is by 
> > However if a router really originates multiple rtr-ids(there seems 
> > to be some possibility), which one(s) should it consider? Should it 
> > having pick node tags/colors from prefix tags can add complexity for 
> > the
> operator.
> >
> > [Pushpasis] Don't see a need of leaking the node-admin tag if the 
> > node itself is not visible across levels. Whatever be the use of 
> > node-admin tag be, it will always need a node to be associated with.
> >
> > > From: [email-masked] [mailto:[email-masked]] 
> > > On Behalf Of Hannes Gredler
> > > On Wed, Oct 23, 2013 at 08:08:00AM +0000, Stefano Previdi 
> > > (sprevidi)
> wrote:
> > It would be easier to judge the appropriateness of the chosen 
> > this apply to RLFA manageability or some other use? Is there a need 
> > to associate a given loopback address with a given node-color?
> >
> > > in theory one could add prefix-tags to IP-subnets ;-) ) - 
> > > therefore we're asking now for dedicated node-colors, (and not 
> > > some heuristics bolted on top of IP prefixes tagging).
> > >
> > > /hannes
> > >

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 30 Oct 2013 09:11:50 +0000

Some more comments.. 

[Les] Also, it would seem that the admin groups could be defined as a variable length bit mask allowing more efficient encoding - and clearly differentiating them from the admin tags already defined for use with prefix reachability advertisements.
[Pushpasis] I believe the prefix tag space should be parallel and completely different form the node-admin tag space(though both will allow same value range). What I mean is a prefix tag value of 1 should not be anyway related to node tag value 1. Operators may choose to derive node-tag based on the prefix-tag associated with certain prefix on the node. But that will still be entirely upto the operator to decide. This solution will still provide that flexibility.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 1:18 AM
To: Pushpasis Sarkar; Hannes Gredler; Stefano Previdi (sprevidi)
Cc: [email-masked]
Subject: RE: [Isis-wg] Soliciting feedback and comments on draft-psarkar-isis-node-admin-tag-00

Pushpasis -

   Les

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 30 Oct 2013 16:28:37 +0100

hi les,

On Wed, Oct 23, 2013 at 06:14:12PM +0000, Les Ginsberg (ginsberg) wrote:
| Hannes -
| 
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On Behalf Of
| > Hannes Gredler
| > Sent: Wednesday, October 23, 2013 1:43 AM
| > To: Stefano Previdi (sprevidi)
| > Cc: [email-masked]; Pushpasis Sarkar
| > Subject: Re: [Isis-wg] Soliciting feedback and comments on draft-psarkar-
| > isis-node-admin-tag-00
| > 
| > On Wed, Oct 23, 2013 at 08:08:00AM +0000, Stefano Previdi (sprevidi) wrote:
| > | > Could admin tag in RFC5130 be used to group nodes in the same domain?
| > |
| > | well, I think so.
| > |
| > | A node can always be represented by its loopback address which carries
| > | one or more tags with any sort of semantic (not dictated by the routing
| > | protocol).
| > 
| > in the most simple case (single loopback address, TE router-ID ==  loopback
| > prefix)
| > prefix-admin-tags MAY be used to identify a node.
| > 
| > it starts getting a bit hairy when any of the above assumption is not true
| > (e.g. multiple loopback addresses or e.g. empty intersection of TE router-ID
| > to
| > the prefixes that a node originates). - which prefix represents then
| > the 'node-identity' ?
| 
| It would be easier to judge the appropriateness of the chosen encoding if you could clarify the "multiple loopback" use case.
| Does this apply to RLFA manageability or some other use? Is there a need to associate a given loopback address with a given node-color? 

it fits in the area both of RLFA managebility (non-TE) and
doing constrained based routing (aka TE)

there is a category of path constraints which requires that a certain
path should or should not be routed over a node with specific
properties.

examples for those path constraints are:

  -go over the packet-optical super-core
  -don't go over any other PE router
  -don't go over any other ASBR (hot potato)
  -don't go over equipment from vendor X
  -don't go over equipment which is running software version x.y.z
  -de-prefer nodes which have not good hardware based latency measurements

as you can see all of the above are essentially node-properties.
 
| As currently defined it would be impossible to leak the node information - is that limitation intentional? 

yes, as path-computation problems are typically area-scoped;
i haven't found so far a good use-case where i want to know
a nodes link-color and not know how the nodes and links
are connected to each other.

/hannes

| (BTW, I don't worry too much about the "empty intersection" case. While theoretically possible it would likely render the router ID useless - which means it is simply a misconfiguration.)
| [ ... ]
| > 
| > for link-colors we have a dedicated link-specific extension
| > (following your logic one could argue that we do not need that,
| > as in theory one could add prefix-tags to IP-subnets ;-) ) -
| > therefore we're asking now for dedicated node-colors,
| > (and not some heuristics bolted on top of IP prefixes tagging).
| > 
| > /hannes