RE: Update to Multi-instance Multi-Topology Draft available

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:hannes <at> juniper.net]
> 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:

Re: Update to Multi-instance Multi-Topology Draft available

On Jul 5, 2006, at 1:56 AM, Les Ginsberg ((ginsberg)) wrote:

> 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:hannes <at> juniper.net]
>> 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

Re: Update to Multi-instance Multi-Topology Draft available

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 

RE: Update to Multi-instance Multi-Topology Draft available

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:hannes <at> juniper.net]
> Sent: Tuesday, July 11, 2006 11:59 AM
> To: Stefano Previdi (sprevidi)
> Cc: isis mailing list; Les Ginsberg (ginsberg)
> Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft
> available
> 
> 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)

Please reread Section 3.4.2 of the draft. We have taken pains to prevent
such behavior. I agree than any proposal that introduced the possibility

Re: Update to Multi-instance Multi-Topology Draft available

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

IETF66 WG Meeting Minutes

Hi All,

These are the minutes from today's meeting.  Please take a look and  
let me know if anything needs correction.  Else, the chairs will post  
them as is.

Thanks!

Andrew

  

Meeting Notes
ISIS WG
2006-07-11

Document Status:
- Docs progressing
- Recharter in progress
- Still operating under the old rules until things officially change.
- v6 standardization process a bit held up because of a comment from the
IESG that it needs more than a ref to the ISIS spec.  WG chairs are going to
push back on this, since this is deployed and interoperable.

Stefano Previdi
draft-previdi-isis-mi-mt-01.txt

ISIS Extension, new TLV, used to identify the instance of ISIS the packet
belongs to.  The idea is to have multiple instances of isis with full 
separation.  True ships in the night.

Re: Update to Multi-instance Multi-Topology Draft available

Hannes,

On Jul 11, 2006, at 11:55 PM, Hannes Gredler wrote:
> On Tue, Jul 11, 2006 at 07:21:59PM +0200, stefano previdi 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,

Re: Update to Multi-instance Multi-Topology Draft available

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

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

Re: Update to Multi-instance Multi-Topology Draft available

les,

tx for your responses - see comments inline:

Les Ginsberg (ginsberg) wrote:
>>| 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 ...
> 
> 
> On P2P we make sure we do not send non-zero PDUs to a legacy system.
> Om LANs we use the different mcast addresses so legacy routers do not
> see the non-zero PDUs.
> 
> For the corner case on P2P when for a brief period (due to APS
> switchover or some other event which changes the wiring on the fly) we
> require different system IDs for the non-zero instance to make sure any
> non-zero LSP which might be "leaked" into a legacy router in such a case
> is not used for forwarding.

lets say we have massive flooding in instance #1 plus an APS event.
then we end up getting a lot of instance #1 LSPs getting installed
in instance zero LSDB, which (as you have pointed out correct)
will be recognized as "disconnected" during SPF computation
and not consume any forwarding state. however it will consume LSDB storage

RE: Update to Multi-instance Multi-Topology Draft available

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:hannes <at> juniper.net]
> Sent: Sunday, July 16, 2006 5:47 AM
> To: Les Ginsberg (ginsberg)
> Cc: Stefano Previdi (sprevidi); isis mailing list
> Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft
> available
> 
> les,
> 
> tx for your responses - see comments inline:
> 
> Les Ginsberg (ginsberg) wrote:
> >>| 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 ...
> >
> >
> > On P2P we make sure we do not send non-zero PDUs to a legacy system.
> > Om LANs we use the different mcast addresses so legacy routers do
not
> > see the non-zero PDUs.
> >