Subject: Re: [Isis-wg] Who did you have do an IS-IS source/destination routing project?

From: Hannes Gredler <[email-masked]>
Date: Mon, 28 Jul 2014 18:22:07 +0200

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)
| 
| David
| 
| P.S.: I'll step up and say Hi in the isis session today.
| 
| 
| Loop example: (all costs/metrics equal)
| 
| R1 -- R2 -- R3 -- R4
| 
| - R1 and R4 each have reachable ::/0, with source prefix P1 != P4
| - R2 does not support dst-src routing
| -> R2 will install a ::/0 route pointing to R1 and ignore the
|    reachability from R4 since it has higher cost.
| - R1 will install a ::/0 route with source prefix P4 pointing via R2
| => packets with source P4 loop between R1 and R2
| 
| Discussion regarding the loop situation occured on homenet and ospf
| mailing lists on 2013-02-22 and 2013-02-23.
| 
| 
| On Wed, Jul 23, 2014 at 01:33:12PM +0000, Fred Baker (fred) wrote:
| > Chairs:
| > 
| > FYI, Mikael (Deutsche Telekom AG) is interested in IS-IS
| > source/destination routing, and asked David to do a prototype in
| > Quagga based on my draft of a while back. The question is how to
| > document and standardize the result. We will need to discuss that with
| > you, and with the working group.
| > 
| > On Jul 23, 2014, at 7:40 AM, David Lamparter <[email-masked]> wrote:
| > > Fred, Mikael,
| > > 
| > > On Wed, Jul 23, 2014 at 12:57:31PM +0200, Mikael Abrahamsson wrote:
| > >> On Wed, 23 Jul 2014, Fred Baker (fred) wrote:
| > >>> He asked to collaborate with me, and I asked me to send me an email,
| > >>> and I would send him a bunch of material. If you can give me his
| > >>> email address, I’d like to send him an email.
| > > 
| > > Indeed that was me, apologies, I didn't assume immediate activity on
| > > this.
| > > 
| > > I've yet to go look at the history/previous comments from when the
| > > isis-srcdest draft was originally posted.  I'm aware of the large
| > > appendix on ospf-dst-src-routing-02, which as far as I remember is the
| > > piece to be moved around, but need to check back on details.
| > > 
| > > So - what are the next steps on this?
| > 
| > David:
| > 
| > From my perspective, you have implemented the technology and will have things you learned in the process. Part of that is “this text was difficult to understand”, and either you have text to suggest or hope I do. Part of that is things I left out, which again you may have suggestions or need to ask me. Part of it is the comment from the rtgwg meeting in which I presented draft-baker-rtgwg-src-dst-routing-use-cases, asking for further discussion of the FIB. Maybe you have other use cases, or Mikael does. Maybe some of the use cases aren’t well stated or are superfluous. There is text in section 2.2 of draft-baker-ipv6-isis-dst-src-routing that was requested in the rtgwg, and I spent some time in appendix B of draft-baker-ipv6-isis-dst-src-routing-00 on lookup mechanisms. 
| > 
| > One of the issues, which I have stated a number of times but not apparently stated well in a draft, is in the attached email message - people would really like to look up the destination and source addresses in that order, or source and destination in that order, and make the right thing happen. I’m of the opinion that each sequential approach has a set of cases it doesn’t cover, and one has to look up the source and destination as a single object to cover them all.
| > 
| > From my perspective, the next step is, as you said in a different message (which I have now read), the thing to do is capture your implementation experience in the draft. I believe that we need the IS-IS Working Group consensus to change the TLA as suggested, which will mean further discussion on [email-masked] and probably mean a presentation in Honolulu. However, I’d like to believe that we can get a fair bit of work done on the mailing list.
| > 
| 
| > Content-Type: multipart/signed;
| >  boundary="Apple-Mail=_6BEFDE79-1C07-4570-9617-F402FD580A92";
| >  protocol="application/pgp-signature"; micalg=pgp-sha1
| > Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
| > Subject: Once again, on ambiguity and the FIB.
| > X-Universally-Unique-Identifier: a86f74de-0cf3-421e-8750-ebe7cfdb3ec4
| > From: Fred Baker <[email-masked]>
| > In-Reply-To: <[email-masked]>
| > Date: Thu, 20 Feb 2014 23:48:13 +1300
| > Cc: Mingwei Xu <[email-masked]>
| > Message-Id: <[email-masked]>
| > X-Smtp-Server: https://[email-masked]/ews/exchange.asmx
| > References: <CAL6OX+1XwamCSUBY8m8tkGmZAb_8=[email-masked]>
| >  <[email-masked]>
| >  <[email-masked]>
| >  <CAL6OX+0h57v0xdvHfwYOqCCpw+AYJHXwAm1m-05V=[email-masked]>
| >  <[email-masked]>
| >  <CAL6OX+1EP3uCgEyWa2RSMEknDR9g=[email-masked]>
| >  <CAL6OX+2=[email-masked]>
| >  <[email-masked]>
| >  <CAL6OX+3vd1ns7Nj1=[email-masked]>
| >  <[email-masked]>
| >  <CAL6OX+3W1kOJ2PGqdp=[email-masked]>
| >  <[email-masked]>
| > To: Shu Yang <[email-masked]>
| > 
| > We seem to travel in circles on this. We come to closure, and then it comes up again. I'm getting frustrated. I'm sorry if I was too short with you in Skype last week.
| > 
| > Here's the ambiguous network:
| > 
| >       ------------------+--       --+---------------------
| >        2001:db8:1::/48  |           |   2001:db8:3:3::/64
| >                      +--+--+      +-+---+
| >                      |     +------'Bob  |
| >                      |     |      +-----+
| >                      |Alice|
| >                      |     |      +-----+
| >                      |     +------+Carol|
| >                      +--+--+      +-+---+
| >                         |           |
| >       ------------------+--        -+--------------------
| >        2001:db8::/40                    2001:db8:3::/48
| > 
| > The route advertisements are that
| > 
| >     2001:db8:1::/48 -> 2001:db8:3::/48   via Carol
| >     2001:db8::/40   -> 2001:db8:3:3::/64 via Bob
| > 
| > In Venn Diagrams:
| >                                                     _.--------.
| >          _.------------.           +-----+      ,-''-----------`--.
| >     ,--'2001:db8::/40 ------------>| Bob |----->(2001:db8:3:3::/64)`.
| >   ,'                         `.    +-----+   /   `---------------'   \
| >  /     ,---------------.       \   +-----+  /                         \
| > (     ( 2001:db8:1::/48 )--------->|Carol|-----> 2001:db8:3::/48       )
| >  \     `---------------'       /   +-----+  \                         /
| >   `.                         ,'              \                       /
| >     '---.               _.--'                 `.                   ,'
| >          `------------''                        '--.           _.-'
| >                                                     `--------''
| > 
| > We have an ambiguous routing situation: the set of addresses matching 2001:db8:1::/48 also match 2001:db8::/40, and the set of addresses matching 2001:db8:3:3::/64 also match 2001:db8:3::/48
| > 
| > The simplest solution is to *also* include a route in the FIB more more specific to more specific, which is to say 
| >      2001:db8:1::/48 -> 2001:db8:3:3::/64, 
| > which obviously has to go via Bob, because Bob is the only one that has connectivity.
| > 
| > You argued in berlin that I don't actually need that, and I would agree if we have a lookup mechanism such as a TCAM or a patricia Tree that can do the entire lookup in one operation.
| > 
| > But OK, so now I have a packet from more specific to more specific, but I don't have the additional route in the FIB.
| >              2001:db8:1::1 -> 2001:db8:3:3::1
| > 
| > However, if I have separate or cascaded FIBs and look up the source first, longest match first gets me to the FIB for 2001:db8:1::/48, and 2001:db8:1::/48 can't get me to Bob - only Carol. So I have no route. 
| > 
| > 
| > Now, repeat the question with a destination-first lookup, and modify the network diagram by adding one router and changing a prefix:
| > 
| >     ------------------+--       --+------------------------+----
| >      2001:db8:1::/48  |           |   2001:db8:3:3::/64    |
| >                    +--+--+      +-+---+                    |
| >                    |     +------'Bob  |               +----+---+
| >                    |     |      +-----+               |        |
| >                    |Alice|                            | Dave   |
| >                    |     |      +-----+               |        |
| >                    |     +------+Carol|               +----+---+
| >                    +--+--+      +-+---+                    |
| >                       |           |                        |
| >     ------------------+--        -+------------------------+----
| >      2001:db8:2::/48                   2001:db8:3::/48
| > 
| > with the rules
| >     2001:db8:1::/48 -> 2001:db8:3::/48   via Carol
| >     2001:db8:2::/48 -> 2001:db8:3:3::/64 via Bob
| > 
| > If I do a destination lookup and then treat the source address as an access list, excluding things that don't match, Alice will try to forward a packet 
| >      2001:db8:1::1 ->  2001:db8:3:3::1 
| > via Bob, and will decide not to because both addresses don't match the rule. However, if Alice noted that 2001:db8:3:3::/64 is a subset of 2001:db8:3::/48 and forwarded it to Carol, in the worst case Carol would have no route and drop the packet, and in the given case could actually get it to the destination via Dave.
| > 
| > 
| > So both in the case where one mandates that one look up the source first and in the case where one mandates that one look up the destination first, cases exist in which a packet that *could*, within the rules, get from a source to a destination is dropped because of the order in which one did the lookup.
| > 
| > The statement that I made in draft-baker-rtgwg-src-dst-routing-use-cases was that 
| > 
| >    o  The FIB lookup yields the route with the most specific (e.g.
| >       longest-match) destination prefix that also matches the source
| >       prefix constraint, or no match.
| > 
| > I think that is the right answer. In the second case I note in this email (which I should probably write up in an internet draft, as it seems controversial), the FIB lookup should find and act on the rule 2001:db8:1::/48 -> 2001:db8:3::/48, even though 2001:db8:3:3::/64 is a more specific destination lookup, because it matches both prefixes.
| 
| 
| 
| > 
| 
| 
|

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 28 Jul 2014 17:00:33 +0000

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:[email-masked]] On Behalf Of Hannes
> Gredler
> Sent: Monday, July 28, 2014 9:22 AM
> To: David Lamparter
> Cc: [email-masked]
> Subject: Re: [Isis-wg] Who did you have do an IS-IS source/destination
> routing project?
> 
> hi david,
> 
> | > From my perspective, you have implemented the technology and will
> have things you learned in the process. Part of that is “this text was difficult
> to understand”, and either you have text to suggest or hope I do. Part of that
> is things I left out, which again you may have suggestions or need to ask me.
> Part of it is the comment from the rtgwg meeting in which I presented draft-
> baker-rtgwg-src-dst-routing-use-cases, asking for further discussion of the
> FIB. Maybe you have other use cases, or Mikael does. Maybe some of the
> use cases aren’t well stated or are superfluous. There is text in section 2.2 of
> draft-baker-ipv6-isis-dst-src-routing that was requested in the rtgwg, and I
> spent some time in appendix B of draft-baker-ipv6-isis-dst-src-routing-00 on
> lookup mechanisms.
> | >
> | > One of the issues, which I have stated a number of times but not
> apparently stated well in a draft, is in the attached email message - people
> would really like to look up the destination and source addresses in that
> order, or source and destination in that order, and make the right thing
> happen. I’m of the opinion that each sequential approach has a set of cases
> it doesn’t cover, and one has to look up the source and destination as a
> single object to cover them all.
> | >
> | > From my perspective, the next step is, as you said in a different message
> (which I have now read), the thing to do is capture your implementation
> experience in the draft. I believe that we need the IS-IS Working Group
> consensus to change the TLA as suggested, which will mean further
> discussion on [email-masked] and probably mean a presentation in Honolulu.
> However, I’d like to believe that we can get a fair bit of work done on the
> mailing list.
> | >
> |
> | > References:
> <CAL6OX+1XwamCSUBY8m8tkGmZAb_8=[email-masked]
> ail.com>
> <[email-masked].
> com>
> <CAL6OX+1EP3uCgEyWa2RSMEknDR9g=[email-masked]
> ail.com>
> | >
> <CAL6OX+2=[email-masked]
> il.com>
> <CAL6OX+3vd1ns7Nj1=[email-masked]
> om>
> | > We seem to travel in circles on this. We come to closure, and then it
> comes up again. I'm getting frustrated. I'm sorry if I was too short with you in
> Skype last week.
> | >
> | > We have an ambiguous routing situation: the set of addresses matching
> 2001:db8:1::/48 also match 2001:db8::/40, and the set of addresses matching
> 2001:db8:3:3::/64 also match 2001:db8:3::/48
> | >
> | > The simplest solution is to *also* include a route in the FIB more more
> specific to more specific, which is to say
> | > You argued in berlin that I don't actually need that, and I would agree if
> we have a lookup mechanism such as a TCAM or a patricia Tree that can do
> the entire lookup in one operation.
> | >
> | > But OK, so now I have a packet from more specific to more specific, but I
> don't have the additional route in the FIB.
> | > However, if I have separate or cascaded FIBs and look up the source first,
> longest match first gets me to the FIB for 2001:db8:1::/48, and
> 2001:db8:1::/48 can't get me to Bob - only Carol. So I have no route.
> | >
> | >
> | > Now, repeat the question with a destination-first lookup, and modify
> the network diagram by adding one router and changing a prefix:
> | >
> | > If I do a destination lookup and then treat the source address as an
> access list, excluding things that don't match, Alice will try to forward a
> packet
> | > via Bob, and will decide not to because both addresses don't match the
> rule. However, if Alice noted that 2001:db8:3:3::/64 is a subset of
> 2001:db8:3::/48 and forwarded it to Carol, in the worst case Carol would
> have no route and drop the packet, and in the given case could actually get
> it to the destination via Dave.
> | >
> | >
> | > So both in the case where one mandates that one look up the source first
> and in the case where one mandates that one look up the destination first,
> cases exist in which a packet that *could*, within the rules, get from a
> source to a destination is dropped because of the order in which one did the
> lookup.
> | >
> | > I think that is the right answer. In the second case I note in this email
> (which I should probably write up in an internet draft, as it seems
> controversial), the FIB lookup should find and act on the rule 2001:db8:1::/48
> -> 2001:db8:3::/48, even though 2001:db8:3:3::/64 is a more specific
> destination lookup, because it matches both prefixes.
> |
> |
> |
> | >
> |
> |
> |
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: David Lamparter <[email-masked]>
Date: Mon, 28 Jul 2014 19:34:21 +0200

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

> > | (can resend this to WG mailing list if you believe that to be more
[cut]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 28 Jul 2014 20:37:07 +0000

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

> From: David Lamparter [mailto:[email-masked]]
> Sent: Monday, July 28, 2014 10:34 AM
> To: Les Ginsberg (ginsberg)
> Cc: Hannes Gredler; [email-masked]
> Subject: Re: [Isis-wg] Capability TLV vs. Router ID (was: IS-IS
> source/destination routing project)
> 
> Les, Hannes, isis-wg,
> 
> 
> > 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.
> >
> > 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
> >
> >

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 28 Jul 2014 21:10:49 +0000

> 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)

--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, July 28, 2014 1:37 PM
To: David Lamparter
Cc: Hannes Gredler; [email-masked]
Subject: Re: [Isis-wg] Capability TLV vs. Router ID (was: IS-IS source/destination routing project)

David -

   Les

> [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.]
> 
> problem.)  There is no stable unique IPv4 address, in fact there may 
> not be IPv4 at all.
> 
> 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
> distribution, where the TLV<>Router association is clear from the 
> LSP's originating router.
> 
> > In regards to Router-Id, again this is NOT TE specific. The 
> > requirement in
> RFC 5305 is
> >
> > " a single
> > > From: Isis-wg [mailto:[email-masked]] On Behalf Of 
> > > Hannes Gredler
> > > 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
> > >
> > > | 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:
> > > | 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]

---

From: David Lamparter <[email-masked]>
Date: Mon, 28 Jul 2014 23:38:30 +0200

>     - 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!

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 28 Jul 2014 23:31:23 +0000

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

> From: Isis-wg [mailto:[email-masked]] On Behalf Of David
> Lamparter
> Sent: Monday, July 28, 2014 2:39 PM
> To: Uma Chunduri
> Cc: Les Ginsberg (ginsberg); Hannes Gredler; [email-masked]
> >                - 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)
> >     - it could be *critical* to have MT  semantics as deployment can be only
> specific to one topology (and may not have V4 at all)
> 
> > 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?
> >
> > 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.
> >

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 29 Jul 2014 01:52:44 +0000

>- 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:[email-masked]] 
Sent: Monday, July 28, 2014 4:31 PM
To: David Lamparter; Uma Chunduri
Cc: Hannes Gredler; [email-masked]
Subject: RE: [Isis-wg] Capability TLV vs. Router ID (was: IS-IS source/destination routing project)

David -

   Les

> > > If TLV 144 semantics are a fit you could use that TLV and thereby 
> > > avoid
> the worry about not having a router-id
> >
> >      - as it is rightly identified below there may not be 4 byte 
> > unique router-
> ID  required by 242
> 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.
> 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 
> 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.
> >
> ospfv3-autoconfig-06.txt . This would allow you to conform to TLV 242 
> more strictly.
> > I think you need define your requirements more clearly in order to 
> > make
> the best choice.
> >
> >    Les
> >
> > > [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.
> > >
> > > 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
> > > 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
> > > Then again, the result might be different when we've gotten a 
> > > proper look at the multitopology interactions.
> > >
> > > Cheers,
> > >
> > > -David
> > >
> > > > > anyway) - do not care much wether we open-up 242 to IIHs or 
> > > > > use a new top-level code-point.
> > > > >
> > > > > @les - opinions ?
> > > > >
> > > > > /hannes
> > > > >
> > > > > | 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.
> > > > > | 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
> > > > > |   other reserved value), while forbidding cross-level 
> > > > > | flooding when
> this
> > > > > |   value is used. (S=0)
> > > > > |

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 29 Jul 2014 03:15:55 +0000

Uma -

You are not talking about the deployment requirements which this thread is about. We are not discussing how to transition an existing network which is in non-MT mode to MT mode - nor even how to introduce IPv6 to an IPv4 only network. What is being discussed is what are the possible deployments for bringing up a brand new IPv6 only network. My understanding of David's concern was that he thought if he chose to use MTID #2 for IPv6 that the use or non-use of MTID #0 might be relevant. I am only pointing out that is not the case. 

I agree that if there is the possibility of supporting IPv4 and IPv6 someday that MT provides more flexibility because if you do that from day one you don't have to worry if the two topologies are not fully congruent - even temporarily.

David - if my understanding of your requirements is incorrect please set me straight. The point of this thread is to address your questions and concerns - hopefully we are doing that.

   Les

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Monday, July 28, 2014 6:53 PM
> To: Les Ginsberg (ginsberg); David Lamparter
> 	>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.
> 
> 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.
> 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.