Re: [Isis-wg] Capability TLV vs. Router ID (was: IS-IS source/destination routing project)

[David Lamparter <[e-mail]>]

Les, Hannes, isis-wg,


TL;DR: 242 works, we simply have no unique 4-byte identifier.


[we have another ongoing discussion thread regarding dst-src routing wrt
MT-ISIS, there may be changes to what exactly is needed as a result of
that.  We didn't really take MT into consideration so far - now TLV 144
is a candidate too.]

the scope in this particular case is area wide, and I'd indeed like to
use TLV 242.  The problem is simply, in the homenet we don't have a
router ID.  (So, this isn't a dst-src problem, this is a homenet
problem.)  There is no stable unique IPv4 address, in fact there may not
be IPv4 at all.

We have the NET, which currently there is a collision resolution
algorithm for, but - that's a heap of complexity that is only there
because "$vendor could mess up again and produce routers with the same
MAC address."  It's really supposed to be the MAC addr.

As a result, autoconfiguring a 4-byte ID, while possible, is way down on
the list of desirable things to do.  Hence, I would like to specify TLV
242 with router ID 0.0.0.0 and S=0 for application in area-wide
distribution, where the TLV<>Router association is clear from the LSP's
originating router.

Then again, the result might be different when we've gotten a proper
look at the multitopology interactions.

Cheers,

-David

On Mon, Jul 28, 2014 at 05:00:33PM +0000, Les Ginsberg (ginsberg) wrote:
> Hannes/David -
> 
> Advertising a capability whose scope is area wide (or domain wide) in hellos is inappropriate. TLV 242 was created precisely for this purpose.
> 
> TLV 242 is NOT TE specific - you can see that by the fact that there are already existing uses which are NOT TE related.
> 
> In regards to Router-Id, again this is NOT TE specific. The requirement in RFC 5305 is
> 
> " a single
>       stable address that can always be referenced in a path that will
>       be reachable from multiple hops away, regardless of the state of
>       the node's interfaces."
> 
> RFC 5305 also explicitly states that a router id can be used for purposes other than TE - so I do not see why TLV 242 is insufficient in this case.
> 
>    Les
> 
> 
> > -----Original Message-----
> > From: Isis-wg [mailto:[e-mail]] On Behalf Of Hannes
> > Gredler
> > Sent: Monday, July 28, 2014 9:22 AM
> > To: David Lamparter
> > Cc: [e-mail]
> > Subject: Re: [Isis-wg] Who did you have do an IS-IS source/destination
> > routing project?
> > 
> > hi david,
> > 
> > i'd be in favour of a CAP registry for IIH (long-term
> > we need that anyway) - do not care much wether we open-up 242
> > to IIHs or use a new top-level code-point.
> > 
> > @les - opinions ?
> > 
> > /hannes
> > 
> > On Thu, Jul 24, 2014 at 05:21:01PM +0200, David Lamparter wrote:
> > | (IS-IS parts in this mail, match behaviour in separate mail)
> > |
> > | Fred, WG Chairs:
> > |
> > | Regarding the IS-IS part, we didn't find major issues while implementing
> > | draft-baker-ipv6-isis-dst-src-routing-01, though there is one issue that
> > | needs broader concern.  We need to signal a router's capability to do
> > | dst-src routing, in order to prevent loops when a reachability with
> > | source prefix is behind a router that does not have this capability.
> > | (The latter router may send the packets back by matching another,
> > | shorter non-specific route for the same destination prefix, since it
> > | doesn't consider the source match more specific.  Loop example included
> > | below.)
> > |
> > | Now there is a small issue with this capability indication - there is no
> > | generic IS-IS capability TLV, only the TE-targeted RFC4971 (TLV 242)
> > | which uses a quad-octet Router ID.  We have no such router ID and would
> > | prefer to not elect/autoconfigure one.  This leaves us with these
> > | possibilities:
> > | - create a "dst-src capable" TLV, wasting a top codepoint
> > | - create a "generic" capability TLV without router ID (maybe including
> > |   NET instead, for inter-level flooding)
> > | - adjust the 242 capability TLV to permit router-id 0.0.0.0 (or some
> > |   other reserved value), while forbidding cross-level flooding when this
> > |   value is used. (S=0)
> > |
> > | I don't have useful arguments in this regard and would appreciate input
> > | (can resend this to WG mailing list if you believe that to be more
> > | appropriate)
[cut]