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

[Uma Chunduri <[e-mail]>]

	>- but there is no reason to have angst about MTID #0. Some context:
              > .....
	>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.

The key word which is laying low is the "consistency" ... it's also can be called congruency..

1. You can use MTID = 0 in MT mode advertising prefixes 235s (for V4), 237s( for V6).. 
2. You can use NO MT and just use 236 (for V6)
3. Or MT transition i.e., both 237 and 236 (for say V6)
4. You can have MTID= 2 and use 237 (V6)

In #1, #2 #3 (when partial deployments are there with MT non-MT)  make *sure* your topology is indeed congruent for V4 and V6 AFs else you can potentially  black hole the traffic.
Our customers (at least few guys had enough and switched to #4).
--
Uma C.


-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[e-mail]] 
Sent: Monday, July 28, 2014 4:31 PM
To: David Lamparter; Uma Chunduri
Cc: Hannes Gredler; [e-mail]
Subject: RE: [Isis-wg] Capability TLV vs. Router ID (was: IS-IS source/destination routing project)

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