Subject: Re: [Isis-wg] Advertising Generic Application Information in IS-IS

From: Hannes Gredler <[email-masked]>
Date: Thu, 8 Mar 2007 11:00:03 +0100

les, et al,

is there a specific reason why IIHs are excluded from using the GENINFO TLV ?

given its generic nature, one can easy think of applications that only want
to convey link-local relevant information.

BTW the same question applies also to the caps code draft.

/hannes

On Fri, Feb 09, 2007 at 03:48:36PM -0800, Les Ginsberg (ginsberg) wrote:
| 
| Folks -
| 
| A new draft is now available:
| 
| http://www.ietf.org/internet-drafts/draft-ginsberg-isis-genapp-00.txt
| 
| 
| Given the recent popularity in using IS-IS LSPs in support of
| advertising of application information, we became concerned about a
| variety issues related to such usage including:
| 
|    o Potential TLV type consumption
|    o Inappropriate use of TLVs intended to carry protocol information
|    o Inefficient encoding due to the use of nested levels of subTLVs
|    o Optimal flooding behavior related to such information
| 
| This draft addresses all of those issues.
| 
| Your comments are invited.
| 
|    Les

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

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Thu, 8 Mar 2007 21:58:48 -0800

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Thursday, March 08, 2007 2:00 AM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]
> Subject: Re: [Isis-wg] Advertising Generic Application Information in
IS-
> IS
> 
> les, et al,
> 
> is there a specific reason why IIHs are excluded from using the
GENINFO
> TLV ?

Such a use amounts to peer-to-peer communication. Is there some reason
why utilizing the normal network/transport layer protocols to send such
a message is not adequate?

  Les

> | A new draft is now available:
http://www.ietf.org/internet-drafts/draft-ginsberg-isis-genapp-00.txt

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 9 Mar 2007 13:00:28 +0100

On Thu, Mar 08, 2007 at 09:58:48PM -0800, Les Ginsberg (ginsberg) wrote:
| Hannes -
| 
| > -----Original Message-----
| > From: Hannes Gredler [mailto:[email-masked]]
| > Sent: Thursday, March 08, 2007 2:00 AM
| > To: Les Ginsberg (ginsberg)
| > Cc: [email-masked]
| > Subject: Re: [Isis-wg] Advertising Generic Application
| > Information in IS-IS
| > 
| > les, et al,
| > 
| > is there a specific reason why IIHs are excluded from using the
| > GENINFO TLV ?
| > 
| > given its generic nature, one can easy think of applications
| > that only want to convey link-local relevant information.
| 
| Such a use amounts to peer-to-peer communication. Is there some reason
| why utilizing the normal network/transport layer protocols to send such
| a message is not adequate?

les,

the way i understand the geninfo idea is to build a service-discovery
protocol on top of IS-IS with either a per-level or a domain wide-scope.

i certainly can see applications, which:

  a. require link-local service discovery
  b. are not specifically tied to the IS-IS base protocol.

examples could be:

  1. measuring probes for dynamic computation of
     link-specific parameters {loss, rtt}

  2. BFD enhancements
     - letting BFD hold-down an IS-IS adjacency,
     - for multiple IP addresses, tell the BFD peer with IP address to connect to
     - for IPv4 and IPv6 operations tell the BFD peer to open a session
           for IPv4 and/or IPv6

---

i also do sense some conceptual overlap between the capcode draft and the
geninfo draft. could you give some rationale what cannot be done from
an applications point of view, with capcodes that can be done with geninfo ?

/hannes

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Fri, 9 Mar 2007 09:02:15 -0800

Hannes -

> Sent: Friday, March 09, 2007 4:00 AM
IS-
>      - for IPv4 and IPv6 operations tell the BFD peer to open a
session

Without commenting on the specific examples you propose, I will state
that I am opposed to the use of IIHs for carrying application
information. The primary purpose of hellos is to discover/maintain
adjacencies. As such, processing primarily consists of verifying that
the information received is identical to the information received
previously. Anything which increases the information content and
includes information which is expected to change over time detracts from
the primary function of hellos and is therefore undesirable.

I would also argue that sending information which changes relatively
slowly in a PDU which is sent at frequent intervals is extremely
inefficient.

> an applications point of view, with capcodes that can be done with
geninfo

The CAPS draft is targeted at sending information about the capabilities
of a router(sic).

The GENINFO draft is targeted at sending application information which
is not required to be associated with a router (which is not the same
thing as saying that an application may not be related to routing).

The format of the GENINFO TLV provides considerably more freedom by
allowing the sub-TLVs to be scoped on a per application basis. This
eliminates conflicts between sub-TLV assignments for different
applications and minimizes the need for the use of nested levels of
sub-TLVs which introduces inefficiency in the encoding. The draft
therefore removes encoding restricions which might require the
consumption of additional TLV codepoints as the number of applications
defined increases.

With the definition of GENINFO, the need to utilize CAPS on behalf of
applications is eliminated. CAPS can then be restricted to what it was
originally intended for - router capabilities - in which case the
sub-TLV limitation for CAPS should not present any practical problem.

   Les

> ?

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 14 Mar 2007 09:46:13 +0100

les,

On Fri, Mar 09, 2007 at 09:02:15AM -0800, Les Ginsberg (ginsberg) wrote:
| > les,
| > 
| > the way i understand the geninfo idea is to build a service-discovery
| > protocol on top of IS-IS with either a per-level or a domain
| wide-scope.
| > 
| > i certainly can see applications, which:
| > 
| >   a. require link-local service discovery
| >   b. are not specifically tied to the IS-IS base protocol.
| > 
| > examples could be:
| > 
| >   1. measuring probes for dynamic computation of
| >      link-specific parameters {loss, rtt}
| > 
| >   2. BFD enhancements
| >      - letting BFD hold-down an IS-IS adjacency,
| >      - for multiple IP addresses, tell the BFD peer with IP address to
| >        connect to
| >      - for IPv4 and IPv6 operations tell the BFD peer to open a
| >            session for IPv4 and/or IPv6
| > 
| 
| Without commenting on the specific examples you propose, I will state
| that I am opposed to the use of IIHs for carrying application
| information. The primary purpose of hellos is to discover/maintain
| adjacencies. As such, processing primarily consists of verifying that
| the information received is identical to the information received
| previously. Anything which increases the information content and
| includes information which is expected to change over time detracts from
| the primary function of hellos and is therefore undesirable.

one could argue that the purpose of LSPs is to convey link states,
however it turns out that we use LSPs meanwhile for far more purposes.
and the simple reason for that is that its a practical thing to do.

| I would also argue that sending information which changes relatively
| slowly in a PDU which is sent at frequent intervals is extremely
| inefficient.

you mean e.g. like IP adresses, areas and adjacency states ... ;-) - 
once again i try to see it from a practical point of view and i can
see some value in link-local service/parameter discovery.

| > i also do sense some conceptual overlap between the capcode draft and the
| > geninfo draft. could you give some rationale what cannot be done from
| > an applications point of view, with capcodes that can be done with
| geninfo
| 
| The CAPS draft is targeted at sending information about the capabilities
| of a router(sic).

more generalized: its a way of advertising service attributes for a node
being identified using a 32-bit integer.

| The GENINFO draft is targeted at sending application information which
| is not required to be associated with a router (which is not the same
| thing as saying that an application may not be related to routing).
| 
| The format of the GENINFO TLV provides considerably more freedom by
| allowing the sub-TLVs to be scoped on a per application basis. This
| eliminates conflicts between sub-TLV assignments for different
| applications and minimizes the need for the use of nested levels of
| sub-TLVs which introduces inefficiency in the encoding. The draft
| therefore removes encoding restricions which might require the
| consumption of additional TLV codepoints as the number of applications
| defined increases.
| 
| With the definition of GENINFO, the need to utilize CAPS on behalf of
| applications is eliminated. CAPS can then be restricted to what it was
| originally intended for - router capabilities - in which case the
| sub-TLV limitation for CAPS should not present any practical problem.

interesting - so they whole purpose of this draft is to improve packing
efficiency ? - altough a functional equivalent could have been done
using CAPS ?

if thats the case then i am a bit resistant to re-invent the wheel,
especially since in our dual-IGP (IS-IS, OSPF) world the same effort
needs to be taken for OSPF.

IMO the resulting confusion from functional identical drafts is not
worth the reduced pain of packing inefficiency.

/hannes

---

From: "Parker, Jeff" <[email-masked]>
Date: Wed, 14 Mar 2007 10:42:48 -0400

> worth the reduced pain of packing inefficiency.

I thought Les' comment was not about the space requirement so much as about the idea of sending information that changed slowly in a packet that is sent often.  

I agree that IP address and adjacency also change slowly.  However, when they change we want a rapid response.  

There is still lots of spare room in a minimal-sized Hello packet.  
This would add processing time to verify that there has been no change.   

> needs to be taken for OSPF.

Has OSPF adopted this proposal?

- jeff parker

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]
Sent: Wed 3/14/2007 4:46 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
Subject: Re: [Isis-wg] Advertising Generic Application Information in IS-IS
 
les,

/hannes

---

From: mike shand <[email-masked]>
Date: Wed, 14 Mar 2007 15:13:23 +0000

I agree that there is perhaps already too much information in IIHs 
(which is one of the reasons we invented BFD to minimize the amount 
of information which needed to be repeatedly and frequently 
transmitted). However, this doesn't seem like a good argument to add 
even more baggage to the hellos.

The hellos have a specific function in forming and verifying the 
continued viability of adjacencies. I don't think adding extraneous 
information to that function is helpful. The existing information 
content is confined to that required for the operation of the routing 
protocol itself.

A similar argument can of course be voiced against adding extraneous 
information to LSPs, and I have a lot of sympathy with that argument. 
However, in that case we are piggybacking on a fairly complex and 
sophisticated reliable broadcast algorithm. Re-inventing that wheel 
seems like a lot of work.

By contrast, exchange of information between two adjacent nodes is 
not exactly challenging. Invention of special purpose "algorithms" 
tuned to the particular "application" requirements doesn't seem like 
such a bad idea, and allows that information flow to be decoupled 
from that of routing.

         Mike

At 14:42 14/03/2007, Parker, Jeff wrote:
>I thought Les' comment was not about the space requirement so much 
>as about the idea of sending information that changed slowly in a 
>packet that is sent often.
>
>I agree that IP address and adjacency also change slowly.  However, 
>when they change we want a rapid response.
>

---

From: Tony Li <[email-masked]>
Date: Wed, 14 Mar 2007 09:43:12 -0700

On Mar 14, 2007, at 8:13 AM, mike shand wrote:

> A similar argument can of course be voiced against adding  
> extraneous information to LSPs, and I have a lot of sympathy with  
> that argument. However, in that case we are piggybacking on a  
> fairly complex and sophisticated reliable broadcast algorithm.

I have to express some support for that stance.  Architecturally,  
adding application load onto the critical infrastructure of an IGP  
seems extremely risky and unwise.  It's creating a bidirectional  
coupling between bulk applications and infrastructure services that  
flies completely in the face of the usual goal of loosely coupled  
subsystems.

I also agree that getting flooding right is fairy complex and  
sophisticated, but wouldn't it be better to simply replicate the  
entire mechanism for generic utilization?

Regards,
Tony

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Wed, 14 Mar 2007 10:23:18 -0700

> From: Tony Li (tli)
> Sent: Wednesday, March 14, 2007 9:43 AM
> To: Mike Shand (mshand)
> Cc: Parker, Jeff; Hannes Gredler; [email-masked]; Les Ginsberg
> (ginsberg)
IS-
> entire mechanism for generic utilization?

I am also very sympathetic to this point of view.

Both the GENAPP draft and the EXTLSP draft are indicative of a very
begrudging acceptance on our part that, despite years of quiet
resistance, we have been unable to prevent the continued expansion of
the use of LSPs/LSAa for purposes not directly related to the operation
of the IGPs.

It is not clear to me that there is the collective will/desire to alter
this trend - it has come to seem to me like "tilting at windmills" - but
I would certainly be supportive of a movement in that direction.

   Les