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

[David Lamparter <[e-mail]>]

On Mon, Jul 28, 2014 at 09:10:49PM +0000, Uma Chunduri wrote:
> > If TLV 144 semantics are a fit you could use that TLV and thereby avoid the worry about not having a router-id
> 
> I would See 144 is the right choice.
> 
> Quick thoughts on why -
> 
>      - as it is rightly identified below there may not be 4 byte unique router-ID  required by 242
>                - auto-configuration is to uniquely assign system ID and need not extend this to create router-ID  (as meaning of this is different for ISIS)
>     - No need to scope this capability across domain (what 242 gives)
>     - it could be *critical* to have MT  semantics as deployment can be only specific to one topology (and may not have V4 at all)

Indeed I'm currently trying to find out if there are any problems with
doing MT, but I believe there aren't, and we should indeed move all of
this to MT ID #2.  (And then use TLV 144 for the capability.)

On the per-topology question - well, in a way it's the natural thing to
do, since the ability to process routes with a source attribute is
essentially a property of the underlying RIB.  In fact dst-src is pretty
much impossible with multicast RPF lookups - there's no src prefix when
doing that.  So for MT ID #4 it'd be invalid to list this capability.
(Also, the capability makes no sense for IPv4 topologies.  No dst-src
for IPv4.)

But - I need a little time to go through the implications of this.  The
argument for using MT-ID 2 is that we can have divergent IPv4/IPv6
topologies, but as far as I can currently see, even with MT we'll run
into problems sunsetting IPv4 (because it's the default topology.)


-David


P.S.: Uma, thanks for pointing out the need for MT in the first place!

> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Monday, July 28, 2014 1:37 PM
> To: David Lamparter
> Cc: Hannes Gredler; [e-mail]
> Subject: Re: [Isis-wg] Capability TLV vs. Router ID (was: IS-IS source/destination routing project)
> 
> David -
> 
> The significant difference between TLV 242 and TLV 144 is that the former has node semantics while the latter has topology semantics. Among other things this means that TLV 242 supports both area scoped and domain scoped flooding whereas TLV 144 is confined to a single area (or potentially the L2 sub-domain). It isn't clear to me why dst-src routing capability needs to be announced per topology - perhaps you can clarify that?
> 
> If TLV 144 semantics are a fit you could use that TLV and thereby avoid the worry about not having a router-id.
> 
> Alternatively, you could employ router-id assignment semantics equivalent to what is specified in http://www.ietf.org/id/draft-ietf-ospf-ospfv3-autoconfig-06.txt . This would allow you to conform to TLV 242 more strictly.
> The IS-IS autoconfig draft does not currently have this - presumably because it was not thought of as necessary.
> 
> I think you need define your requirements more clearly in order to make the best choice.
> 
>    Les
> 
> > -----Original Message-----
> > From: David Lamparter [mailto:[e-mail]]
> > Sent: Monday, July 28, 2014 10:34 AM
> > To: Les Ginsberg (ginsberg)
> > Cc: Hannes Gredler; [e-mail]
> > Subject: Re: [Isis-wg] Capability TLV vs. Router ID (was: IS-IS 
> > source/destination routing project)
> > 
> > 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]
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg