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

["Les Ginsberg (ginsberg)" <[e-mail]>]

David -

I think you are considering the right issues - but there is no reason to have angst about MTID #0. Some context:

Conceptually, the association of AFI(s) with a given topology is arbitrary. There can be one or many AFIs supported on a given topology - though all routers participating in that topology need to be consistent in their AFI support. RFC 5120 reserved a small number of MTIDs for specific purposes - MTID #2 for IPv6 only is one of them.

In the case of MTID #0 (legacy), it is quite possible to support IPv4 only, IPv6 only, or IPv4 and IPv6 on MTID #0. All are legal deployments though (to repeat) all routers participating in the topology have to behave consistently.
It is also possible to support/deploy MTID #2 without supporting MTID #0 at all.

   Les

> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of David
> Lamparter
> Sent: Monday, July 28, 2014 2:39 PM
> To: Uma Chunduri
> Cc: Les Ginsberg (ginsberg); Hannes Gredler; [e-mail]
> Subject: Re: [Isis-wg] Capability TLV vs. Router ID (was: IS-IS
> source/destination routing project)
> 
> 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
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg