Subject: RE: [Isis-wg] Update to Multi-instance Multi-Topology Draft available

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Tue, 4 Jul 2006 16:56:05 -0700

Hannes -

Here is a more complete reply to the points you have raised.

By way of preface, assume that an MI-capable router will use a different
system ID for non-zero IID instances than it does for the instance
associated with IID #0. We don't state this in the draft, but it is not
prohibited either. In consideration of the points you raise, it is
probably a good practice - and a future version of the draft will
discuss this.

What this means is that even in the contexts you raise below, in the
unlikely event a legacy router receives an IS-IS PDU associated w a
non-zero IID, it will always be seen as having originated from a system
which is unreachable in the IID #0 topology. Therefore, such a PDU will
not alter routing behavior in the IID #0 topology.

More detailed responses inline.

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Friday, June 23, 2006 5:07 PM
> To: Les Ginsberg (ginsberg); Stefano Previdi (sprevidi)
> Cc: isis mailing list
> Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft
> available
> 
> 
> 
> Les Ginsberg (ginsberg) wrote:
> 
> > We gave a lot of thought to backwards compatibility - and discussed
> > those issues in the draft. If you are not convinced we considered
all
> > issues, please point out a specific problem (or problems) that you
> > believe we overlooked.
> 
> i don't think the restrictions on p2p interfaces will practically
> work. - there is all sort of real-world strangeness (reconfig, APS)
> that could break this. it is easy to makeup a series of events
> where e.g. a LSP from a non-zero instance could end-up in instance 0.
> 

The window of opportunity here is the time between the "strange event"
and the receipt of the first hello (which, due to 3way handshake logic,
will cause the adjacency to be reinitialized). Should a non-zero IID LSP
or SNP PDU arrive, it could find its way into the legacy router's LSPDB.
However as the originating system will be unreachable (due to the
different system ID used for non-zero) this will not affect routing in
IID #0 topology.

It is also worth mentioning that the same sort of event could happen
today even without MI extensions. For example, if A has a neighbor B on
a P2P. The "strange event" happens and A is now connected to C on the
same interface. A could receive an LSP from C prior to the reception of
an IIH. This LSP could be added to A's LSPDB. If C were in a different
area, this might not be appropriate. 

So MI does not introduce a new risk here - and with the use a different
system ID for non-zero instances the dangers are certainly no greater
than in current deployments.

> >>   we should not use subnet dependend fields (like MAC adresses)
> >>   to control the versioning.
> >
> >
> > That isn't what we are doing. We use a different MAC address to
insure
> > that legacy implementations won't see the PDUs they cannot correctly
> > process. The protocol behavior hasn't changed at all - but we do
need a
> > way to allow multiple instances to run on a LAN and be invisible to
> > legacy implementations.
> 
> there is an underlying assumption that implementations actually parse
> the dest-MAC adress for sanitizing the PDU. if memory serves me
correct
> then iso10589 does not contain a sanity check rule that requires
> to check the destination-MAC adress against the configured Level.
> 
> in addition i know of at least two widely deployed implementations
that
> do not do, or did not do this ;-)
>

Your answer to a follow up question from me indicates that we agree that
incoming multicast PDUs pass through a lower level address filter before
being delivered to IS-IS code. Therefore, the use of a new multicast
destination address will prevent legacy implementations from ever seeing
an IS-IS PDU associated with a non-zero IID which is sent on a LAN.

Your concern seems to be that in order to support MI extensions, some
implementations might have to modify hard coded filter logic which might
be part of the kernel code. So this isn't an interoperability concern,
but rather a concern on your part that the MI implementation cost in
some cases could be higher than you would like.

I invite other folks on the list to indicate whether this is a
significant concern.
 
> >>since this is a essentially a redefinition of
> >>   all known TLVs [which are from now on now keyed by the
instance-id]
> >>   have you thought about using a different PDU version in the IS-IS
> >>   common header ?
> >>
> >>   suggestion:
> >>      pdu-version 1 would be used for topology 0 [fully downwards
> >>                    compatible] and
> >>      pdu-version 2 would be used for the per-instance-keyed
> >>                    topologies.
> >>
> >>   all PDU type and TLV allocations stay as-is.
> >>
> >>   that way you rule out any subnet specific dependencies and any
node
> >>   that does not understand pdu-version 2 will ignore it anyway,
which
> is
> >>   IMO a cleaner transition tool.
> 
> > One of the wonderful things about IS-IS is that it has survived for
a
> > long time now and has been extended in many ways without need for a
new
> > protocol version. Such robustness is to be respected and not
discarded
> > lightly. Spinning a new version is a major step and one which the
> > community has thus far consciously avoided - with good reason I
think.
> > I see nothing in the proposal which suggests this is a desirable
> > approach, let alone necessary. But, I'll keep listening...
> 
> TLVs are fine for doing incremental changes - but what you are
suggesting
> here is to change the semantics of every TLV ever defined (which is to
> be keyed by the instance-id) - if you want to do that in a clean way
> then you need IMO redefine all TLVs (undesirable) or bump the pdu
version
> field. -

I stand by my previous comments regarding a new protocol version.

Spinning a new protocol version quite rightly demands a higher set of
requirements than is generally applied to releasing a new version of a
software implementation. Given that this would be the first new version
in the history of the IS-IS protocol, it is reasonable to assume that
before taking such a step we would solicit requests for other changes
which might be incorporated at the same time. (I am sure many of us have
a few things which we might like to see...) Based on the experience of
other protocols, I am guessing a few years from now we might have
reached agreement. Of course, noting that in this case the base spec is
owned by ISO (not IETF), it might take a bit longer. :-)

It is legitimate to debate whether MI can be supported in an
interoperable way in the current protocol version. If the collective
wisdom of the WG is "no", then I think MI gets thrown onto the pile of
things that shouldn't be done now.

> 
> 
> >>finally a question: how would i link nodes between different
> >> topologies if i wanted to do so ?
> 
> > This sounds like a trick question. :-)
> 
> oh it isn't - i just wanted to check if there is a way to keep
seperate
> topologies and still have them connected on a choke point.
> 
> ---
> 
> another question which i don't really understand:
> 
> what problem does MI solve that cannot be solved using MT ?
> (apart from the 12-Bit vs. 16-Bit Topology/Instance space
> difference).
>

MI solves the same problem as MT, but it allows for a greater degree of
fault isolation. This has been a significant concern for some in the
community. YMMV

   Les

> /hannes

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: stefano previdi <[email-masked]>
Date: Wed, 5 Jul 2006 11:45:11 +0200

> fault isolation. This has been a significant concern for some in the

yes, this is the first motivation: having a router with
different and isolated routing instances but sharing one
or more interfaces. Today, MT doesn't allow this since
everything is in the same LSP/LSDB/Flooding.

This of course doesn't mean MI should be a replacement
for MT... it's just an answer to a specific requirement.

s.

---

From: stefano previdi <[email-masked]>
Date: Tue, 11 Jul 2006 19:21:59 +0200

On Jul 11, 2006, at 5:55 PM, Hannes Gredler wrote:

> hi les,
>
> tx for your responses - see answers/comments inline.
>
> On Tue, Jul 04, 2006 at 04:56:05PM -0700, Les Ginsberg (ginsberg) 
> wrote:
> [ ... ]
> | By way of preface, assume that an MI-capable router will use a 
> different
> | system ID for non-zero IID instances than it does for the instance
> | associated with IID #0. We don't state this in the draft, but it is 
> not
> | prohibited either. In consideration of the points you raise, it is
> | probably a good practice - and a future version of the draft will
> | discuss this.
>
> tx for adding this - adding an applicability note [read: virtual
> routers sharing a interface] would make obvious what this draft
> is about and confine MI usage vs. MT usage.
>
> | So MI does not introduce a new risk here - and with the use a 
> different
> | system ID for non-zero instances the dangers are certainly no greater
> | than in current deployments.
>
> i have to disagree -
> today a neighbor-id change is treated as a reconfig event i.e. the 
> existing
> adjacency is torn down and a new adjacency is kickstarted for the 
> new-sysid.
> a MI router interfacing to a non-MI router will hence cause constant 
> adjacency
> flaps.

the draft explicitly says that a MI-router not seeing
the appropriate IID in received  hello packets will not
form any adjacency. No bouncing.

LEs proposal looks good to me as using different SysIDs
fix the misconfig issue you raised.

> that is not my definition of smooth downwards compatability.
> you should find a way for a MI draft such that MI PDUs hitting a non-MI
> router are silently ignored.
>
> | Your answer to a follow up question from me indicates that we agree 
> that
> | incoming multicast PDUs pass through a lower level address filter 
> before
> | being delivered to IS-IS code. Therefore, the use of a new multicast
> | destination address will prevent legacy implementations from ever 
> seeing
> | an IS-IS PDU associated with a non-zero IID which is sent on a LAN.
>
> i was just raising concerns that implementations may not do this.
> [in fact i have seen some implmentations that even were relying on
> BPF filters [in lack of proper kernel support]]. i agree that kernels
> *should* be doing this, but i have concerns that everybody *does* it.
>
> | Your concern seems to be that in order to support MI extensions, some
> | implementations might have to modify hard coded filter logic which 
> might
> | be part of the kernel code. So this isn't an interoperability 
> concern,
> | but rather a concern on your part that the MI implementation cost in
> | some cases could be higher than you would like.
>
> we all want to standardize _simple_ protocols that are easy to 
> implement
> and hence proper interoperate. if you go down suggesting protocol
> extensions (in fact protocol redefinitions) that are non-trivial
> to implement then you are creating in fact entrance barriers for folks
> who don't have the power to change routing *and* kernel code and
> rely on 3rd parties to do this. my employer is in the lucky position
> to be in control of the ISO kernel stack and able to make the required
> changes, my concern is for the folks that don't have this freedom
> of choice.
>
> | [ ... ]
> | Spinning a new protocol version quite rightly demands a higher set of
> | requirements than is generally applied to releasing a new version of 
> a
> | software implementation. Given that this would be the first new 
> version
> | in the history of the IS-IS protocol, it is reasonable to assume that
> | before taking such a step we would solicit requests for other changes
> | which might be incorporated at the same time. (I am sure many of us 
> have
> | a few things which we might like to see...) Based on the experience 
> of
> | other protocols, I am guessing a few years from now we might have
> | reached agreement. Of course, noting that in this case the base spec 
> is
> | owned by ISO (not IETF), it might take a bit longer. :-)
>
> well i guess this WG has a nice track record of not caring too much 
> about
> "ownership" questions. furthermore i do think that MI does qualify
> "a higher set of requirements" because it is re-defining the gross 
> semantics
> of the protocol [=key each and every TLV by the MI-ID].
>
> | [ ... ]
> | It is legitimate to debate whether MI can be supported in an
> | interoperable way in the current protocol version. If the collective
> | wisdom of the WG is "no", then I think MI gets thrown onto the pile 
> of
> | things that shouldn't be done now.
>
> don't get me wrong - i do sense customer on our end asking for virtual
> routers being able to share interfaces as well.
> i just want to make the deployment as smooth as possible
> and avoiding hickups of all kind.
>
> the draft as it is today with its assumptions that everybody would be
> able to filter on MAC adresses plus the kludge on p2p interfaces does
> not warrant smooth downwards compatibility with non-MI routers.
>
> IMO there are two wyas to fix this:
>
> 1. define a new set of TLVs for MI usage, similar to the work being 
> done
>    for MT (MI-IS_REACH, MI-IP_REACH)

re-inventing the whole set of TLVs looks a bit overkilling
to me.

s.

>
> 2. leave it as is wrt new TLV definition and find a dead-sure way of
>    interoperating with non-MI routers.(bumping the pdu-version field
>    seems to be the only drastic-enough measure to warrant that)
>
> i am happy with both solution paths (have a slight favour for option 
> #1)
> as it would be in-line with the incremental nature of IS-IS protocol
> extensions so far ...
>
> i also want to encourage other folks to speak-up and hear their
> opinions.
>
> tx,
>
> /hannes
>

---

From: stefano previdi <[email-masked]>
Date: Tue, 11 Jul 2006 21:17:00 +0200

Hannes,

my concern is that a misconfiguration should not cause
permanent/long loops/blackholes and Les proposal ensure
this.

A misconfigured network having adj bouncing is something
we could expect... even if I don't think it's the case in
mi-isis draft (as Les explained).

Similar issue happens when you configure the same SysID
to different routers (LSP bouncing).

Mistakes don't come for free...

s.

On Jul 11, 2006, at 8:58 PM, Hannes Gredler wrote:
> On Tue, Jul 11, 2006 at 07:21:59PM +0200, stefano previdi wrote:
> [ ... ]
> | the draft explicitly says that a MI-router not seeing
> | the appropriate IID in received  hello packets will not
> | form any adjacency. No bouncing.
>
> stefano,
>
> sorry, perhaps i was unclear what concerns me -
> let me illustrate this by an example:
>
> lets assume we have a MI router talking to a non-MI
> router over a p2p interface. the MI router wants to
> establish adjacencies for instances {0,1}. now the
> non-MI router gets constantly confused by the two different
> sysids and constantly is bouncing the instance 0 adjacency.
> (in fact it cannot proper distinguish between the two instances)
>
> | Les' proposal looks good to me as using different SysIDs
> | fix the misconfig issue you raised.
>
> the draft would need a safety belt way such that
> non-0 instance PDUs are silently ignored by non-MI
> implementations. dealing with misconfigs at the level
> of adjacency FSM is already too late and one instance
> may impact the other ...
>
> /hannes
>

---

From: stefano previdi <[email-masked]>
Date: Wed, 12 Jul 2006 17:53:56 +0200

Hannes,

On Jul 11, 2006, at 11:55 PM, Hannes Gredler wrote:
> |
> | On Jul 11, 2006, at 5:55 PM, Hannes Gredler wrote:
> [ ... ]
> | >1. define a new set of TLVs for MI usage, similar to the work being
> | >done
> | >   for MT (MI-IS_REACH, MI-IP_REACH)
> |
> | re-inventing the whole set of TLVs looks a bit overkilling
> | to me.
>
> no shortcuts here ;-) - i do sense from your statement above
> that you admit that MI *does* redefine the interpretation of all ever
> defined TLVs so far ...

hmmm don't you sense that I believe mi-isis solves a clear
and simple problem in a simple way with minimal protocol
extension that do not require massive ietf/itu negotiation ?

> and that sounds like a perfect
> application for bumping the pdu-version field to flag that
> the TLVs contained in a PDU would need non-default treatment.

I'm afraid if you go that path you will collect many other
requirements and good reasons to incorporate other changes...

I'm not sure it's a good idea for this specific case. Again,
we are fixing a simple problem with a simple solution...

> i don't get why you are resistant to use the pdu-version
> field for this purpose [i still have not get a sound technical
> explanation why *not* to use it] utilizing the pdu-version field
> would fix a bunch of real-world misconfigs issues in a
> non-disruptive way.

but I believe the concern you reported has been addressed
by the draft.

s.

> furthermore it would not make any assumptions
> about underlying media-type nor ability of the kernel to
> filter based on L2-mcast etc.
>
> /hannes
>

---

From: Hannes Gredler <[email-masked]>
Date: Sun, 16 Jul 2006 13:32:29 +0200

> extension that do not require massive ietf/itu negotiation ?

no offense here ... it is just the nature of the change
(one TLV affecting interpretation of all the others)
that is unprecedented of IS-IS related protocol work so far,
and that was raising red flags to me.

i hope its just paranoia on my side and the potential
unwanted MI fallout will eventually turn out to be
"simple" fixable as well.

/hannes