draft-ietf-lsr-isis-flood-reflection-01.txt   draft-ietf-lsr-isis-flood-reflection-02.txt 
Network Working Group A. Przygienda Network Working Group A. Przygienda
Internet-Draft C. Bowers Internet-Draft C. Bowers
Intended status: Standards Track Juniper Intended status: Standards Track Juniper
Expires: January 28, 2021 Y. Lee Expires: July 22, 2021 Y. Lee
A. Sharma A. Sharma
Comcast Comcast
R. White R. White
Juniper Juniper
July 27, 2020 January 18, 2021
IS-IS Flood Reflection IS-IS Flood Reflection
draft-ietf-lsr-isis-flood-reflection-01 draft-ietf-lsr-isis-flood-reflection-02
Abstract Abstract
This document describes an optional ISIS extension that allows the This document describes an optional ISIS extension that allows the
creation of IS-IS flood reflection topologies. Flood reflection creation of IS-IS flood reflection topologies. Flood reflection
allows the creation of topologies where L1 areas provide transit allows the creation of topologies where L1 areas provide transit
forwarding for L2 destinations within an L2 topology. It forwarding for L2 destinations within an L2 topology. It
accomplishes this by creating L2 flood reflection adjacencies within accomplishes this by creating L2 flood reflection adjacencies within
each L1 area. The L2 flood reflection adjacencies are used to flood each L1 area. The L2 flood reflection adjacencies are used to flood
L2 LSPDUs, and they are used in the L2 SPF computation. However, L2 LSPDUs, and they are used in the L2 SPF computation. However,
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2021. This Internet-Draft will expire on July 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 9, line 47 skipping to change at page 9, line 47
RESERVED: This field is reserved for future use. It MUST be set to RESERVED: This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received. 0 when sent and MUST be ignored when received.
Flood Reflection Cluster ID: Flood Reflection Cluster Identifier. Flood Reflection Cluster ID: Flood Reflection Cluster Identifier.
These same 32-bit value MUST be assigned to all of the flood These same 32-bit value MUST be assigned to all of the flood
reflectors and flood reflector clients in the L1 area. The value reflectors and flood reflector clients in the L1 area. The value
MUST be unique across different L1 areas within the IGP domain. MUST be unique across different L1 areas within the IGP domain.
On a given router, the same value of the Flood Reflection Cluster On a given router, the same value of the Flood Reflection Cluster
ID MUST be advertised across all interfaces advertising the Flood ID MUST be advertised across all interfaces advertising the Flood
Reflection TLV in IIHs. Reflection TLV in IIHs. This implies that a flood reflector can
participate in a single L1 area only.
Sub-TLVs: Optional sub-TLVs. For future extensibility, the format Sub-TLVs: Optional sub-TLVs. For future extensibility, the format
of the Flood Reflection TLV allows for the possibility of of the Flood Reflection TLV allows for the possibility of
including optional sub-TLVs. No sub-TLVs of the Flood Reflection including optional sub-TLVs. No sub-TLVs of the Flood Reflection
TLV are defined in this document. TLV are defined in this document.
The Flood Reflection TLV MUST NOT appear more than once in an IIH. A The Flood Reflection TLV MUST NOT appear more than once in an IIH. A
router receiving multiple Flood Reflection TLVs in the same IIH router receiving multiple Flood Reflection TLVs in the same IIH
SHOULD use the values in the first TLV. SHOULD use the values in the first TLV.
skipping to change at page 12, line 39 skipping to change at page 12, line 39
7. Flood Reflection Adjacency Formation 7. Flood Reflection Adjacency Formation
In order to simplify both implementations and network deployments, we In order to simplify both implementations and network deployments, we
do not allow the formation of complex hierarchies of flood reflectors do not allow the formation of complex hierarchies of flood reflectors
and clients. All flood reflectors and flood reflector clients in the and clients. All flood reflectors and flood reflector clients in the
same L1 area MUST share the same Flood Reflector Cluster ID. A flood same L1 area MUST share the same Flood Reflector Cluster ID. A flood
reflector MUST only form flood reflection adjacencies with flood reflector MUST only form flood reflection adjacencies with flood
reflector clients. A flood reflector MUST NOT form any traditional reflector clients. A flood reflector MUST NOT form any traditional
L2 adjacencies. Flood reflector clients MUST only form flood L2 adjacencies. Flood reflector clients MUST only form flood
reflection adjacencies with flood reflectors. Flood reflector reflection adjacencies with flood reflectors. Flood reflector
clients may form traditional L2 adjacencies with flood reflector clients MAY form traditional L2 adjacencies with flood reflector
clients or nodes not participating in flood reflection. clients or nodes not participating in flood reflection.
The Flood Reflector Cluster ID and flood reflector roles advertised The Flood Reflector Cluster ID and flood reflector roles advertised
in the Flood Reflection TLVs in IIHs are used to ensure that flood in the Flood Reflection TLVs in IIHs are used to ensure that flood
reflection adjacencies that are established meet the above criteria. reflection adjacencies that are established meet the above criteria.
Once a flood reflection adjacency is established, the flood reflector Once a flood reflection adjacency is established, the flood reflector
and the flood reflector client MUST advertise the adjacency by and the flood reflector client MUST advertise the adjacency by
including the Flood Reflection Adjacency Sub-TLV in the Extended IS including the Flood Reflection Adjacency Sub-TLV in the Extended IS
reachability TLV or MT-ISN TLV. reachability TLV or MT-ISN TLV.
skipping to change at page 14, line 24 skipping to change at page 14, line 24
A flood reflector with directly L2 attached prefixes should advertise A flood reflector with directly L2 attached prefixes should advertise
those in L1 as well since based on preference of L1 routes the those in L1 as well since based on preference of L1 routes the
clients will not try to use the L2 flood reflector adjacency to route clients will not try to use the L2 flood reflector adjacency to route
the packet towards them. A very, very corner case is when the flood the packet towards them. A very, very corner case is when the flood
reflector is reachable via L2 flood reflector adjacency (due to reflector is reachable via L2 flood reflector adjacency (due to
underlying L1 partition) only in which case the client can use the L2 underlying L1 partition) only in which case the client can use the L2
tunnel to the flood reflector for forwarding towards those prefixes tunnel to the flood reflector for forwarding towards those prefixes
while it MUST initiate an alarm and declare misconfiguration. while it MUST initiate an alarm and declare misconfiguration.
A flood reflector SHOULD NOT set the attached bit on its LSPs.
Instead of modifying the computation procedures one could imagine a Instead of modifying the computation procedures one could imagine a
flood reflector solution where the Flood Reflector would re-advertise flood reflector solution where the Flood Reflector would re-advertise
the L2 prefixes with a 'third-party' next-hop but that would have the L2 prefixes with a 'third-party' next-hop but that would have
less desirable convergence properties than the solution proposed and less desirable convergence properties than the solution proposed and
force a fork-lift of all L2 routers to make sure they disregard such force a fork-lift of all L2 routers to make sure they disregard such
prefixes unless in the same L1 domain as the Flood Reflector. prefixes unless in the same L1 domain as the Flood Reflector.
Depending on pseudo-node choice in case of a broadcast domain with Depending on pseudo-node choice in case of a broadcast domain with
multiple flood reflectors attached this can lead to a partitioned LAN multiple flood reflectors attached this can lead to a partitioned LAN
and hence a router discovering such a condition MUST initiate an and hence a router discovering such a condition MUST initiate an
 End of changes. 8 change blocks. 
7 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/