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

From: "Chen, Jay (Jay)" <[email-masked]>
Date: Tue, 1 Nov 2011 14:20:29 -0500

"An existing limitation of the protocol defined by [IS-IS] is that only one instance of the protocol can operate on a given circuit. This document defines an extension to IS-IS to remove this restriction."

If a forwarding, for example, is using circuit-ipv4/6 to indicate a specific per-instance-topology table, circuit-ipv4/6 pair will no longer be unique. When data traffic coming from wire, how to take advantage of the specific routing forwarding table, will some new fields to the data packets need to be added and looked to make forwarding decision ?

Could we have some more use cases or more explanation for any of the questions like below:  
A. How it interoperate with ISIS LFA (< 50ms local protection)
B. Isolation of topology/instance, and sharing circuit seems a conflict goal to achieve. Any consideration of BW sharing, COS (in or out of scope) ?

Jay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, October 30, 2011 10:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Isis-wg] I-D Action: draft-ietf-isis-mi-05.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)       : Stefano Previdi
                          Les Ginsberg
                          Mike Shand
                          Abhay Roy
                          Dave Ward
	Filename        : draft-ietf-isis-mi-05.txt
	Pages           : 14
	Date            : 2011-10-30

   This draft describes a mechanism that allows a single router to share
   one or more circuits among multiple Intermediate System To
   Intermediate System (IS-IS) routing protocol instances.

   Multiple instances allow the isolation of resources associated with
   each instance.  Routers will form instance specific adjacencies.
   Each instance can support multiple topologies.  Each topology has a
   unique Link State Database (LSDB).  Each Protocol Data Unit (PDU)
   will contain a new Type Length Value (TLV) identifying the instance
   and the topology(ies) to which the PDU belongs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-mi-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-isis-mi-05.txt
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 1 Nov 2011 12:56:49 -0700

Jay -

Your questions are all related to using MI for routing - which is a
legitimate use case and I will reply to your questions inline. However,
I also want to point out that the primary motivator for this draft is in
support of flooding application information:

http://datatracker.ietf.org/doc/draft-ietf-isis-genapp/

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Chen, Jay (Jay)
> Sent: Tuesday, November 01, 2011 12:20 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-mi-05.txt
> 
> "An existing limitation of the protocol defined by [IS-IS] is that
only
> one instance of the protocol can operate on a given circuit. This
> document defines an extension to IS-IS to remove this restriction."
> 
> If a forwarding, for example, is using circuit-ipv4/6 to indicate a
> specific per-instance-topology table, circuit-ipv4/6 pair will no
> longer be unique. When data traffic coming from wire, how to take
> advantage of the specific routing forwarding table, will some new
> fields to the data packets need to be added and looked to make
> forwarding decision ?

How an implementation chooses to map a particular packet to a particular
topology is out of scope for the draft.
Note that the problem you mention (i.e. incoming interface and AFI is
not topology unique) also applies to RFC 5120 - and that document also
(quite wisely) does not address this issue.

> A. How it interoperate with ISIS LFA (< 50ms local protection)

LFA calculation is always on a specific topology - so IPFRR solutions
care applicable to any topology.

> B. Isolation of topology/instance, and sharing circuit seems a
conflict
> goal to achieve. Any consideration of BW sharing, COS (in or out of
> scope) ?

This is out of scope.

   Les

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