Internet DRAFT - draft-hegde-rtgwg-virtual-multi-instance
draft-hegde-rtgwg-virtual-multi-instance
Routing area S. Hegde
Internet-Draft Salih. K.A
Intended status: Standards Track Juniper Networks
Expires: September 22, 2016 M. Venkatesan
Comcast
R. Callon
A. Atlas
Juniper Networks
March 21, 2016
Virtual multi-instancing for link state protocols
draft-hegde-rtgwg-virtual-multi-instance-01
Abstract
In networks with routers of different capabilities, some routers may
not be able to participate fully in supporting new features or
handling large databases and the associated flooding. In some cases,
these restrictions can cause severe scalability issues for the
network in general. This document proposes virtual multi-instances,
a generic mechanism for OSPF and IS-IS, that allows groups of routers
in specific topologies to have a reduced database and reduces the
topology changes that are seen. The virtual multi-instances are
specified so that no software or protocol changes are required in the
restricted routers. Due to the potential number of virtual multi-
instances in a network, the configuration is limited and is not
specified per virtual instance.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Hegde, et al. Expires September 22, 2016 [Page 1]
Internet-Draft Virtual multi-instancing March 2016
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Description . . . . . . . . . . . . . . . . . . . . . 4
2.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Load on Spoke routers . . . . . . . . . . . . . . . . 4
2.1.2. Customer Routers Causing Frequent SPFs . . . . . . . 5
2.1.3. Mixture of Capabilities between Routers . . . . . . . 5
3. Topology Restrictions . . . . . . . . . . . . . . . . . . . . 5
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Identification into Virtual Instances or Virtual Areas . 8
4.2. Route Redistribution . . . . . . . . . . . . . . . . . . 9
4.3. Avoiding Transit Traffic . . . . . . . . . . . . . . . . 10
4.4. Including Hub-to-Hub Links for Ring LSDBs . . . . . . . . 10
4.5. Hierarchical Virtual Multi-Instance . . . . . . . . . . . 10
4.6. Dynamic shortcut Tunnels . . . . . . . . . . . . . . . . 11
5. Hub Router Behavior . . . . . . . . . . . . . . . . . . . . . 11
5.1. Classification into an Virtual Instance/Area . . . . . . 11
5.2. Generating Router LSA/LSPs and Default Routes for Virtual
Instances . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. SPF computations and Route Preference . . . . . . . . . . 12
6. Manageability considerations . . . . . . . . . . . . . . . . 12
7. Backward compatibility . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
Hegde, et al. Expires September 22, 2016 [Page 2]
Internet-Draft Virtual multi-instancing March 2016
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
A router that participates in OSPF or IS-IS must be capable of
handling the entire link state database (LSDB) for the areas or
levels that router participates in. In OSPF, this can be mitigated
by creating small or stub areas, but such areas must still be
configured. In IS-IS, regardless of area address, there can be only
a single Level 1. The need to handle the entire LSDB as well as all
functionality required in that area or level poses a difficulty for
networks that have routers with limited functionality or resources.
In Section 2, the specific problems motivating a solution are
discussed. These problems derive from a mixture of operational
concerns around configuration, equipment with limited resources,
networks with growing numbers of routers, and enhancements in the
IGPs that may be needed to support some services but that can't be
supported by deployed equipment.
The proposed solution is termed virtual multi-instances because the
hub router (termed from a motivating hub-and-spoke topology) is
configured to dynamically treat a neighbour's LSP or LSA as belonging
to a particular instance, that may be created and deleted on demand.
For OSPF, that virtual instance may instead be treated as a virtual
area. The hub router automatically creates the virtual instance,
distributes a default route into the virtual instance, may advertise
specific links into the virtual instance, and redistributes
optionally summarized routes learned from that virtual instance.
Although the solution does not require any extension to existing
protocol standards, the redistribution behaviour should be followed
by hub routers for each of the topologies and hence the need for
standardization of this solution.
The topologies to which virtual multi-instances can be applied are
restricted. In Section 3, the three different types of topologies
are described with different behaviour for route redistribution,
leaking of hub to hub links into the virtual instance, and ensuring a
single hub router LSA/LSP announcement into the virtual instance/
area. The virtual instance or area is distinguished based upon the
hub router's and neighbour's Router-ID or system-id or upon the
neighbour's specified area-id. An overview of the solution is given
in Section 4.
In Section 5, the specific procedures that a hub router must follow
to use virtual multi-instances are defined. Because this solution is
intended to be low-touch to ease manageability, the suggested
Hegde, et al. Expires September 22, 2016 [Page 3]
Internet-Draft Virtual multi-instancing March 2016
configuration aspects are described in Section 6. In Section 8, the
potential security benefits of reducing network visibility and using
different instances are briefly discussed.
2. Problem Description
Hub-and-Spoke topologies are increasingly being used at large scale.
Due to the scale and to improve routing between spokes, dynamic
tunnels between spokes can be established and torn-down on-demand
based on traffic flow. Particularly when combined with routers that
have limited resources and low-feature implementations of IS-IS or
OSPF, these topologies causes real issues in existing networks as
described in Section 2.1.
In a hub-and-spoke network, each spoke in the same area unnecessarily
learns the link information of the other spokes. This extra
information not only grows the size of the LSDB but also causes
additional information flooding with associated SPFs. In OSPF,
spokes can be separated into different areas but this comes with
configuration overhead and can waste IP addresses, since a different
IP address is required per interface per area it is used in. In IS-
IS, because there is only one L1 domain, the only way to create
separated domains is to have separate L1L2 routers for each domain.
While [RFC7356] defines different flooding scopes for IS-IS, the
changes are not backwards compatible and how the information would be
properly processed for basic routing is not defined. In a network,
it is rarely feasible to have multiple L1L2 routers in the same
geographic area simply to separate the flooding domains.
To provide improved routing between spokes, the ability to establish
and tear down dynamic tunnels between spokes on-demand is defined in,
for instance, "Auto Discovery VPN Protocol"
[I-D.sathyanarayan-ipsecme-advpn]. A huge number of dynamic tunnels
can badly impact the scaling of a link-state protocol. At the same
time, these on-demand tunnels can't require configuration overhead to
separate them into different areas.
2.1. Issues
2.1.1. Load on Spoke routers
As discussed, containing a hub-and-spoke network inside a single area
means that all routers carry the full LSDB for the area. This can
overload limited-capability routers or non-router devices that are
frequently used as spoke routers. The use of a limited-capability
router can thus constrain the size of the area.
Hegde, et al. Expires September 22, 2016 [Page 4]
Internet-Draft Virtual multi-instancing March 2016
High Internet traffic growth requires a high number of link and node
updates in metro networks. The number of IP prefixes processed in LS
databases increases, causing longer SPF calculations. Though modern
routers have high CPUs and better resources for faster SPF
calculations, non-router devices typically have limited resources for
processing. The size of the LSDB and frequency of SPFs is a problem
for non-router devices participating in the routing protocol.
2.1.2. Customer Routers Causing Frequent SPFs
In some cases, service-provider-managed CPEs may participate in the
link state routing protocol to advertise their connected and loop-
back interfaces for end-to-end connectivity. Power cycles and device
failure of CPEs can trigger updates to and SPF calculations on all
routers in the domain or area. Isolation of the CPEs from uninvolved
routers is desirable.
2.1.3. Mixture of Capabilities between Routers
A metro L1 network supports many different customers and services,
but the inclusion of non-router devices (such as cable modem
termination systems, video edge devices, voice soft switches, etc.)
that participate in the link state protocol may severely limit the
ability to provide those different services and abilities.
A non-router device typically just gets its default route from the
upstream L1L2 routers for outbound traffic. While that meets the
requirements of the non-router device, the inability of such devices
to support all IS-IS features (e.g. multi-topology) means that the
whole Metro L1 network can't support those features.
It may not be reasonable or economical to request the implementation
of such features on a non-router device that has no need to use them.
A solution is required that can support both non-router devices with
limited routing protocol features and core network devices with
complete routing features. This will allow the Metro L1 network to
provide diversified services to different customers.
3. Topology Restrictions
The issues discussed in Section 2 centre on issues around hub-and-
spoke topologies. In the simplest case, each spoke is connected to a
single hub router as shown in Figure 1. To provide resiliency, a
spoke may be connected to two or more hub routers, as shown in
Figure 2. Since normal link state routing is performed between the
hub and the spoke, the spoke does not need to be a single router, but
could be a small connected group of routers operating as an IS-IS
Hegde, et al. Expires September 22, 2016 [Page 5]
Internet-Draft Virtual multi-instancing March 2016
(level 1) or OSPF area as long as only one among the group of routers
connects to the hub router.
+-------+
| Hub 1 |
+-------+
/ | \
/ | \
+---+ | +---+
|A_1| | |C_1|
+---+ | +---+
/ \ +---+ |
/ | | B | +---+
/ | +---+ |C_2|
+---+ +---+ +---+
|A_2|-|A_3|
+---+ +---+
Figure 1: Different spokes connected to a single Hub
+---------+ +---------+
| Hub_1 | | Hub_2 |
+---------+ +---------+
| \ / |
| \ / |
+-----+ X +-----+
| A_1 | --/ \--| B_1 |
+-----+ +-----+
/ \
+---+ +---+
|A_2|-|A_3|
+---+ +---+
Figure 2: Spokes connected to two Hubs
When there are a huge number of spoke routers, the spokes may be
connecting to set of hubs which in turn connect to a hub at the
higher level making a hierarchical hub and spoke.It is possible to
use virtual multi-instances hierarchically so that a spoke may itself
have spokes or rings that have been summarized.
Increased deployments of hub and spoke topologies has lead to
improved routing requirements between the spokes. A typical
enterprise network with branch offices connecting to head office is
usually deployed using IPSEC VPNs. The Figure 4 shows dynamic tunnel
topology where A and B are spoke routers and a tunnel is created/
teared-down between them on-demand. The handling of a dynamic tunnel
in a virtual instance is slightly different from how a spoke or ring
Hegde, et al. Expires September 22, 2016 [Page 6]
Internet-Draft Virtual multi-instancing March 2016
topology is handled; this is to avoid route redistribution beyond the
two ends of the dynamic tunnel.
Another common topology is to have rings that connect to two hub
routers, which are themselves directly connected; this is shown in
Figure 3; it is possible for additional routers to be connected to
the basic ring as shown in ring F. To support ring topologies, the
two hub-connecting routers are identified as belonging to the same
instance, as described in Section 5 and Section 6. The necessity for
this static configuration is what makes it unsuitable for use with
dynamic tunnels connecting spokes.
+-----+ +-----+
| G_1 |---| G_2 |
+-----+ +-----+
\ /
+---------+ +---------+
| Hub_1 |---| Hub_2 |
+---------+ +---------+
| | | |
| +-----+ +-----+ |
| | E_1 |--| E_2 | |
| +-----+ +-----+ |
| |
+-----+ +-----+ +-----+ +-----+
| F_1 |-| F_2 | -| F_5 |-| F_6 |
+-----+ +-----+ +-----+ +-----+
| |
+-----+ +-----+
| F_3 |-----| F_4 |
+-----+ +-----+
Figure 3: Rings connected to one or two Hubs
+-------+
| Hub 1 |
+-------+
/ \ === is dynamic tunnel
/ \
+---+ +---+
| A |=======| B |
+---+ +---+
Figure 4: Dynamic tunnel connecting single-node spokes
Hegde, et al. Expires September 22, 2016 [Page 7]
Internet-Draft Virtual multi-instancing March 2016
4. Solution Overview
This document defines virtual multi-instances, which is a mechanism
to dynamically create and destroy virtual instances or virtual areas.
A similar result can be obtained by creating virtual stub areas in
OSPF rather than virtual instances. Whether to create virtual
instance or virtual area is an implementation choice.
It is well defined for OSPF and IS-IS how multiple instances can run
across a single interface (see [RFC6549] and [RFC6822]) but to
support multiple instances in this general case, an instance-id is
required in the messages to distinguish which instance is intended.
This also requires that all routers in the non-default instance
support the extensions. Virtual multi-instances removes the
requirement to include the instance-id by both restricting topology
and using router-id/system id or area address as keys to distinguish
the instances.
By isolating spokes, rings and dynamic tunnels into their own virtual
instances, this solution provides isolation for spokes, avoids large
LSDBs and, except for handling dynamic tunnels, the need for spoke
routers to implement additional features in the IGP. The
configuration can be independent of the number of interfaces
affected.
4.1. Identification into Virtual Instances or Virtual Areas
There are three different basic types of topologies supported -
spoke-based, ring-based and dynamic-tunnel based. A hub router will
be configured to know that virtual multi-instance should apply to a
set of interfaces and the topology the interfaces correspond to.
When an IGP peer is connected via one of those interfaces, the hub
router determines the associated instance and, if necessary, creates
it. When the last IGP peer disconnects from a virtual instance, the
hub router can delete the associated instance. If an IGP peer has a
spoke-based or dynamic-tunnel based topology, then the associated
virtual instance is identified by the (hub router router-id/system-
id, IGP peer router-id/system-id).
In OSPF, it is possible to configure rings as separate stub areas.
This requires that all routers in the stub area be configured with
the specific and unique area address. In IS-IS, it is not possible
to have multiple separate (having separate flooding domain) L1 areas
connecting to the same L1/L2 router. For virtual multi-instance to
support ring topologies, a router that connects to the hub must be
configured with an area address. If multiple routers in the same
ring connect to the same hub (routers G_1 and G_2 in Figure 3), then
all those and only those routers must be configured with the same
Hegde, et al. Expires September 22, 2016 [Page 8]
Internet-Draft Virtual multi-instancing March 2016
area address. The hub will create a virtual instance or virtual area
that is identified by the area address. The hub router does not need
to have the area address configured on the set of interfaces to which
virtual multi-instance applies. If a single router in a ring
connects to a given hub (routers E_1, E_2, F_1, and F_6 in Figure 3,
then that router may be configured with a special area address
UNIQUE_RING_AREA_ADDRESS (well-known or explicitly configured) and
the hub will create a virtual instance or virtual area that is
identified by (hub router router-id/system-id, IGP peer router-id/
system-id) but is marked as a ring topology. Virtual instances/areas
that are ring topologies will have hub-to-hub links advertised into
them.
A router may be connected to a hub via multiple links due to
redundancy or to provide sufficient bandwidth. Because a virtual
instance is identified by either (hub router router-id/system-id, IGP
peer router-id/system-id) or an area address, the multiple IGP
adjacencies formed across the parallel links will be in the same
instance.
4.2. Route Redistribution
The route redistribution for virtual instances containing a dynamic
tunnel is different than that for virtual instances with spoke or
ring topologies. For a virtual instance with a dynamic tunnel, only
the ends of the dynamic tunnel should learn about the prefixes in the
virtual instance. This is to prevent traffic from routing down a
spoke and across the dynamic tunnel in order to reach the a
destination on the other spoke. A router at the end of a dynamic
tunnel
o MUST NOT advertise a default route into
o SHOULD redistribute its own prefixes into
o MAY redistribute non-default prefixes from only its default
instance into
o SHOULD NOT redistribute prefixes out of
the associated virtual instance/area.
For spoke and ring topologies, the hub router is responsible for
providing a default route into the virtual instance and for
redistributing the routes learned from a virtual instance into the
default instance. A hub router connected to a spoke or ring topology
o MUST advertise a default route into
Hegde, et al. Expires September 22, 2016 [Page 9]
Internet-Draft Virtual multi-instancing March 2016
o by default, MUST advertise reachability to the addresses that are
learned from
o before exporting into the default instance, MAY summarize routes
from
o by default, MUST NOT leak routes from the default instance into
the associated virtual instance/area.
Routes from one virtual instance SHOULD not be leaked into each other
unless explicitly configured to do so via local policies. By
default, routes from default instance MUST NOT be leaked into the
virtual instances.
4.3. Avoiding Transit Traffic
Via each virtual instance that is connected to two hubs, a hub router
will see a topology to reach the other hub router. However, transit
traffic sent via spokes SHOULD be avoided. After the hub router has
completed its SPFs in each virtual instance/area as well as any non-
virtual instances, the hub router must determine which route is
preferred. Routes learned via a non-virtual instance MUST be
preferred over routes learned via a virtual instance/area.
4.4. Including Hub-to-Hub Links for Ring LSDBs
Rings that include two hubs usually also need to see the link between
the two hubs in their LSDB. This provides redundancy and the
possibility of fast-reroute techniques. The link between the hubs is
in the default instance. The hub-to-hub links will be advertised by
a hub router into all virtual instances/areas that are known to have
a ring topology. A hub router can identify other hub routers either
by configuration or by using determining other routers with the
appropriate node admin tag (see [I-D.ietf-ospf-node-admin-tag] and
[I-D.ietf-isis-node-admin-tag]) in the default instance.
4.5. Hierarchical Virtual Multi-Instance
When considering the use of tunnels to connect spokes towards a hub,
it is possible for hub-and-spoke topologies to scale extremely high.
To reduce the load on particular hubs, it may be useful to consider
topologies that include hierarchy so that a spoke router could act as
a hub for several remote spokes. Since the spoke router is
deliberately unaware that its default instance is being treated as a
virtual instance, there are no additional requirements on a router
supporting virtual multi-instance.
Hegde, et al. Expires September 22, 2016 [Page 10]
Internet-Draft Virtual multi-instancing March 2016
4.6. Dynamic shortcut Tunnels
As previously discussed (see Section 2), virtual multi-instances need
to handle large numbers of dynamic tunnels being created and removed.
By way of an example, consider Figure 1 where router A_2 has a
dynamic tunnel created to C_2. Router A_2 will create a virtual
instance (A_2, C_2) and may redistribute the prefixes associated with
C_2, C_1, and Hub_1 into A_2's default instance. Similarly, C_2 will
create a virtual instance (C_2, A_2) and may redistribute the
prefixes associated with A_1, A_2, A_3, and Hub_1.
Treating a dynamic tunnel as a virtual instance is how dynamic
tunnels need to be handled to avoid multiple different LSAs from the
same hub router being seen by routers in the connected spokes.
Supporting dynamic tunnels does require that router-ends of the
dynamic tunnel router support the virtual multi-instance
functionality as a hub. There are specific different rules for
handling route redistribution (see Section 4.2 for a virtual instance
that contains a dynamic tunnel.
In a common topology such as shown in Figure 4, the two spokes each
contain a single router A or B and those routers are connected by a
dynamic tunnel. In some deployments, it is likely that all
connections from router A are sub interfaces across a single
interface and that single interface is configured for the "dynamic
tunnel topology". In that case, A may treat both the dynamic tunnel
to B and the connection to Hub_1 as separate virtual instances and
follow the route redistribution rules for the "dynamic tunnel
topology" for both. Hub_1 can treat A as being in a "spoke topology"
and thus redistribute the needed default route in and redistribute
the routes learned from A. This combination will provide the correct
behaviour.
5. Hub Router Behavior
5.1. Classification into an Virtual Instance/Area
A received hello, LSupdate or LSP packet needs to be classified as to
which instance it belongs to. The following describes how a Hub
Router MUST do this classification.
1. Was the LSP/LSA received on an interface configured for virtual
multi-instance? If no, select default instance or instance-id in
packet and exit.
2. Was the LSP/LSA received on an interface configured for ring
topology? If yes, goto (4).
Hegde, et al. Expires September 22, 2016 [Page 11]
Internet-Draft Virtual multi-instancing March 2016
3. Assign to instance or area identified by (hub router-id/system-
id, IGP peer source router-id/system-id) and exit.
4. Is the Area ID in the packet the UNIQUE_RING_AREA_ADDRESS? If
yes, assign to instance or area identified by (hub router-id/
system-id, IGP peer source router-id/system-id) and exit.
5. Assign to instance identified by the Area ID and exit.
New virtual instances/areas SHOULD be created when there is no
corresponding instance. With the closing of the last IGP adjacency
associated with a virtual instance/area, that virtual instance/area
MAY be destroyed.
5.2. Generating Router LSA/LSPs and Default Routes for Virtual
Instances
For each virtual instance/area, the Hub Router MUST generate a
separate Router LSA/LSP that includes only the links to IGP peers
identified as part of that virtual instance/area and, if the virtual
instance/area is identified as a ring topology, SHOULD include any
direct links from the Hub Router to another Hub Router.
5.3. SPF computations and Route Preference
A separate SPF calculation SHOULD be done for each virtual instance.
If the same prefix is learned from a non-virtual instance/area, then
its route MUST be preferred over the route via a virtual instance/
area.
6. Manageability considerations
Because of the scale for hub-and-spoke topologies, it is difficult to
manage per-spoke configuration on the hubs. Therefore, virtual
multi-instance does not require per-spoke configuration. The
following are the expected configuration aspects.
o A set of interfaces is specified as configured for virtual multi-
instance. The type of topology - spoke, ring, or dynamic tunnel -
must be specified for the set.
o The set of neighboring hub routers may be specified. This is per
hub neighbor configuration. Alternately, node admin tags may be
supported and one admin tag configured to indicate what other
routers are hub routers.
o A value for the UNIQUE_RING_AREA_ADDRESS may be specified or a
well-known default (TBD) may be used.
Hegde, et al. Expires September 22, 2016 [Page 12]
Internet-Draft Virtual multi-instancing March 2016
o A default route to be advertised into virtual instances/areas may
be defined.
o A summarization policy for redistributing prefixes may be defined.
Ideally, this should apply to a set of virtual instances/areas.
It is expected that virtual multi-instance will be useful to provide
a zero-touch hub for IPSEC VPNs where it is highly desirable to have
no per spoke configuration on the hub router.
7. Backward compatibility
The mechanism described in the document is fully backward compatible.
The mechanism described in this document need to be supported by the
hub and the spokes need not support the mechanism unless they need to
support dynamic tunnels.
8. Security Considerations
This document does not introduce any further security issues other
than those discussed in [RFC2328] and [RFC5340].
When a new spoke connects to the hub, it is restricted in terms of
visibility into the network. This enhances security in terms of
limited exposure to the unauthenticated nodes.Also the ability of a
spoke to perturb the entire area is minimized when summarization is
done. Per spoke authentication is already available and is expected
to work well with virtual multi-instance.
9. IANA Considerations
This document does not currently require any allocations from IANA.
10. Acknowledgements
The authors would like to thank Jeffrey Zhang, Pushpasis Sarkar and
Gil Spolidoro for their suggestions and review.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Hegde, et al. Expires September 22, 2016 [Page 13]
Internet-Draft Virtual multi-instancing March 2016
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
Instance Extensions", RFC 6549, DOI 10.17487/RFC6549,
March 2012, <http://www.rfc-editor.org/info/rfc6549>.
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D.
Ward, "IS-IS Multi-Instance", RFC 6822,
DOI 10.17487/RFC6822, December 2012,
<http://www.rfc-editor.org/info/rfc6822>.
11.2. Informative References
[I-D.ietf-isis-node-admin-tag]
Sarkar, P., Gredler, H., Hegde, S., Litkowski, S.,
Decraene, B., Li, Z., Rodriguez, R., and H. Raghuveer,
"Advertising Per-node Admin Tags in IS-IS", draft-ietf-
isis-node-admin-tag-08 (work in progress), December 2015.
[I-D.ietf-ospf-node-admin-tag]
Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B.
Decraene, "Advertising per-node administrative tags in
OSPF", draft-ietf-ospf-node-admin-tag-09 (work in
progress), November 2015.
[I-D.sathyanarayan-ipsecme-advpn]
Sathyanarayan, P., Hanna, S., Melam, N., Nir, Y., Migault,
D., and K. Pentikousis, "Auto Discovery VPN Protocol",
draft-sathyanarayan-ipsecme-advpn-03 (work in progress),
October 2013.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014,
<http://www.rfc-editor.org/info/rfc7356>.
Authors' Addresses
Hegde, et al. Expires September 22, 2016 [Page 14]
Internet-Draft Virtual multi-instancing March 2016
Shraddha Hegde
Juniper Networks
Embassy Business Park
Bangalore, KA 560093
India
Email: shraddha@juniper.net
Salih K.A
Juniper Networks
Embassy Business Park
Bangalore, KA 560093
India
Email: salih@juniper.net
Mannan Venkatesan
Comcast
1800 Bishops Gate Blvd
Mount Laurel , NJ 08053
USA
Email: mannan_venkatesan@cable.comcast.com
Ross Callon
Juniper Networks
Westford , MA 01886
USA
Email: rcallon@juniper.net
Alia K. Atlas
Juniper Networks
Email: akatlas@juniper.net
Hegde, et al. Expires September 22, 2016 [Page 15]
