Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-mi-03.txt

From: "lan7801" <[email-masked]>
Date: Wed, 27 Oct 2010 11:40:01 +0800

Authors, 

   2.5.2.  Interoperability using p2p networks

    Until an IIH is received from a neighbor, an MI-RTR MAY send IIHs for
   a non-zero instance.  However, once an IIH with no IID TLV has been
   received - indicating that the neighbor is not an MI-RTR - the MI-RTR
   MUST NOT send IIHs for a non-zero instance.  The temporary relaxation
   of the restriction on sending IIHs for non-zero instances allows a
   non-zero instance adjacency to be established on an interface on
   which an MI-RTR does NOT support instance #0.

If both routers on the given links support MI-RTR, who will send the first IIH to establish  adjacency ?

Jame lan
2010-10-27

发件人： Internet-Drafts
发送时间： 2010-07-13 01:21:41
收件人： i-d-announce
抄送： isis-wg
主题： [Isis-wg] I-D Action:draft-ietf-isis-mi-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.
Title           : IS-IS Multi-Instance
Author(s)       : S. Previdi, et al.
Filename        : draft-ietf-isis-mi-03.txt
Pages           : 9
Date            : 2010-07-12
This draft describes a mechanism that allows a single router to share
one or more links among multiple IS-IS routing protocol instances.
Multiple instances allow the isolation of resources associated with
each instance.  Routers will form instance specific adjacencies,
exchange instance specific routing updates and compute paths
utilizing instance specific LSDB information.  Each PDU will contain
a new TLV identifying the instance to which the PDU belongs.  This
allows a network operator to deploy multiple IS-IS instances in
parallel, using the same set of links when required and still have
the capability of computing instance specific paths.  This draft does
not address the forwarding paradigm that needs to be used in order to
ensure data PDUs are forwarded according to the paths computed by a
specific instance.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-mi-03.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 26 Oct 2010 23:28:27 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of lan7801
> Sent: Tuesday, October 26, 2010 8:40 PM
> To: isis-wg
> Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-mi-03.txt
> 
>  Authors,
> 
> 

It does not matter. We are restricting whether an IIH w the IID TLV can be sent AFTER it is discovered that a neighbor does NOT support the extension- as indicated by the lack of the IID TLV in its hellos. So when a P2P circuit is enabled, a router supporting this extension would send IIHs w the IID TLV for all of the instances it supports on that circuit. However, once it receives an IIH without the IID TLV from the neighbor it MUST no longer send any IIHs which have the IID TLV.

So, assume that a router is configured to support Instances #0 (legacy instance) and #2.
On circuit enabling it would send:

IIH w IID TLV Instance #0
IIH w IID TLV Instance #2

If it receives an IIH from the neighbor which does NOT include the IID TLV it knows the neighbor does not support the MI extension. From this point on it will send only:

IIH w/o IID TLV

If it happens that an IIH is received from the neighbor before the initial transmission of an IIH, then it can be determined whether an IIH w an IID TLV can be sent at all.

   Les

> 
> 
> 
> 
> 
> ________________________________
> 
> Jame lan
> 2010-10-27
> ________________________________
> 
> 发件人： Internet-Drafts

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 26 Oct 2010 23:37:17 -0700

One correction below.

> Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, October 26, 2010 11:28 PM
> To: lan7801; isis-wg
> It does not matter. We are restricting whether an IIH w the IID TLV can
> be sent AFTER it is discovered that a neighbor does NOT support the
> extension- as indicated by the lack of the IID TLV in its hellos. So
> when a P2P circuit is enabled, a router supporting this extension would
> send IIHs w the IID TLV for all of the instances it supports on that
> circuit. However, once it receives an IIH without the IID TLV from the
> neighbor it MUST no longer send any IIHs which have the IID TLV.
> 
> If it receives an IIH from the neighbor which does NOT include the IID
> TLV it knows the neighbor does not support the MI extension. From this
> point on it will send only:
> 
> IIH w/o IID TLV

The neighbor will ignore the IID TLV (since it does not support it) but it will correctly interpret it as referring to the legacy instance. What we can no longer do is send an IIH for a non-zero instance as legacy systems will incorrectly interpret that as being associated w instance #0.

Sorry for any confusion.

   Les

> 
> If it happens that an IIH is received from the neighbor before the
> initial transmission of an IIH, then it can be determined whether an
> IIH w an IID TLV can be sent at all.
> 
>    Les
> 
> >
> >
> >
> >
> >