Hannes -
> -----Original Message-----
> From: Hannes Gredler [mailto:hannes juniper.net]
> Sent: Friday, March 09, 2007 4:00 AM
> To: Les Ginsberg (ginsberg)
> Cc: isis-wgietf.org
> Subject: Re: [Isis-wg] Advertising Generic Application
Information in
IS-
> IS
>
> On Thu, Mar 08, 2007 at 09:58:48PM -0800, Les Ginsberg
(ginsberg)
wrote:
> | Hannes -
> |
> | > -----Original Message-----
> | > From: Hannes Gredler [mailto:hannesjuniper.net]
> | > Sent: Thursday, March 08, 2007 2:00 AM
> | > To: Les Ginsberg (ginsberg)
> | > Cc: isis-wgietf.org
> | > 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
>
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.
> ---
>
> 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).
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
> ?
>
> /hannes
_______________________________________________
Isis-wg mailing list
Isis-wgietf.org
https:
//www1.ietf.org/mailman/listinfo/isis-wg
|
