Advertising MPLS labels in OSPFJuniper Networks, Inc.1194 N. Mathilda Ave.SunnyvaleCA94089UShannes@juniper.netLevel 3 Communications, Inc.1025 Eldorado BlvdBroomfieldCO80021USshane@level3.netAmazonSeattleWNUStscholl@amazon.comVerizon1201 E Arapaho Rd.RichardsonTX75081USluay.jalil@verizon.com
Routing
Open Shortest Path First IGPMPLSIGPOSPFLabel advertisementHistorically MPLS label distribution was driven by
protocols like LDP, RSVP and LBGP. All of those protocols are session
oriented. In order to obtain label binding for a given destination FEC from
a given router one needs first to establish an LDP/RSVP/LBGP session
with that router.
Advertising MPLS labels in IGPs
describes several use cases where utilizing the flooding machinery
of link-state protocols for MPLS label distribution allows
to obtain the binding without requiring to establish an LDP/RSVP/LBGP
session with that router.
This document describes the protocol extension to distribute
MPLS label bindings by the OSPFv2 and OSPFv3 protocol.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.MPLS label allocations are predominantly distributed by using
the LDP , RSVP or
labeled BGP protocol. All of those protocols
have in common that they are session oriented, which means that in
order to obtain label binding for a given destination FEC from
a given router one needs first to establish a direct
control plane (LDP/RSVP/LBGP) session with that router.
There are a couple of practical
use cases
where the consumer of a MPLS label binding may not
be adjacent to the router that performs the binding. Bringing up an
explicit session using the existing label distribution protocols between
the non-adjacent router that binds the label and the router that
acts as a consumer of this binding is the existing remedy for
this dilemma. This document describes an OSPFv2 and OSPFv3 protocol extension which allows
routers to advertise MPLS label bindings within and beyond an IGP domain, and
controlling inter-area distribution.
Distributing MPLS labels in an IGP (IS-IS) has been described in
Segment
Routing. The authors propose to re-use existing traffic-engineering
extensions for carrying the label information.
While retrofitting existing protocol machinery for new
purposes is generally a good thing, Segment
Routing falls short of addressing some use-cases defined in
.
The dominant issue around re-using traffic-engineering extensions is that
both have existing protocol semantics, which might not be applicable
to advertising MPLS label switched paths in a generic fashion.
These are specifically:Bi-directionality semanticsIP path semanticsLack of 'path' notion
'Bi-directionality semantics', affects the complexity around advertisement of unidirectional LSPs.
Label advertisement of per-link labels or 'Adj-SIDs'
is done by attaching label information to adjacency advertisment TLVs.
Usually implementations need to have
an adjacency in 'Up' state prior to advertising this adjacency
as TE-Link in its Link State advertisment.
In order to advertise a per-link LSP an implementation first needs to have
an adjacency, which only transitions to 'Up' state after passing the 3-way
check. This implies bi-directionality. If an implementation wants to advertise
per-link MPLS LSPs to e.g. outside the IGP domain then it would need
to fake-up an adjacency. Changing existing IGP Adjacency code to support
such cases defeats the purpose of re-using existing functionality as there is
not much common functionality to be shared.
LSPs pointing to a Node are advertised as 'Node-SIDs'
using IP Prefix containers. That means that in order
to advertise a MPLS LSP, one is inheriting the semantics of advertising an
IP path. Consider router A has got existing LSPs to its entire one-hop
neighborhood and is re-advertising those LSPs using IP reachability semantics.
Now we have two exact matching IP advertisements. One from the owning router
(router B) which advertises its stable transport loopback address and another one
from router A re-advertising a LSP path to router B. Existing routing software
may get confused now as the 'stable transport' address shows up from multiple places
in the network and more worse the IP forwarding path for control-plane protocols may get
mingled with the MPLS data plane.
Both exisiting traffic-engineering extension containers have
limited semantics describing MPLS label-switched paths in the sense of
a 'path'. Both encoding formats allow to express a pointer to some
specific router, but not to describe a MPLS label switched path
containing all of its path segments. allows to define
'Forwarding Adjacencies' as per . The way to
describe a path of a given forwarding adjacency is to enlist a list of
"Segment IDs". That implies that nodes which do not yet participate in
'Segment routing' or are outside of a 'Segment routing' domain can not
be expressed using those path semantics.
A protocol for advertising MPLS label switched paths, should
be generic enough to express paths sourced by existing MPLS LSPs,
such that ingress routers can flexibly combine them according to
application needs.
IGP advertisement of MPLS label switched paths requires a new set of
protocol semantics (undirectional paradigm, path paradigm),
which hardly can be expressed using
the existing OSPF and OSPF-TE protocol semantics.
This document describes protocol extensions
which allows generic advertisement of MPLS label bindings
in the OSPFv2 and OSPFv3 protocol.
The Protocol extensions described in this document are equally
applicable to IPv4 and IPv6 carried over MPLS.
Furthermore the proposed use of distributing
MPLS Labels using IGP prototocols adheres to
the architectural principles laid out in
.
One new LSA is defined, the MPLS Label LSA. This LSA advertises
MPLS labels along with their path information. The LSA contains
more specific information encoded in TLVs. Those TLV extensions are
shared between the OSPFv2 and OPSFv3 protocols.
The LSA ID of an Opaque LSA is defined as having eight bits
of type data and 24 bits of type-specific data. The MPLS Label LSA
uses type 149. The remaining 24 bits are 4 zero bits followed by the
MPLS Label or MPLS Label Base value as follows:
The 'MPLS Label' field holds the 20 Bit MPLS label for
MPLS Label base.
Therefore a maximum of 2^20 MPLS Label LSAs may be sourced
by a single system.
This extension makes use of the Opaque LSAs .
Three types of Opaque LSAs exist, each of which has a different
flooding scope. This proposal uses only Type 10 LSAs, which have an
area flooding scope.
The MPLS Label LSA for OSPFv2 starts with the standard OSPFv2 LSA header:
The OSPFv3 LSA ID of an MPLS Label LSA is defined as having twelve bits
of zero followed by the 20-Bit label MPLS Label value as follows:
The 'MPLS Label' field holds the 20 Bit MPLS label or MPLS
label base value.
Therefore a maximum of 2^20 MPLS Label LSAs may be sourced
by a single system.
The MPLS Label LSA for OSPFv3 starts with the standard OSPFv3 LSA header:
The OSPFv3 'U' Bit will always be set such that routers which
do not understand the new MPLS Label LSA will store and forward
it further.
In analogy to the OSPFv2 opaque LSA 10 the flooding scope will be
set to 'Area scoping'.
The LSA payload consists of one or more nested Type/Length/Value
(TLV) triplets for extensibility. The format of each TLV is:
The Length field defines the length of the value portion in
octets (thus a TLV with no value portion would have a length of zero).
The TLV is padded to four-octet alignment; padding is not included in
the length field (so a three octet value would have a length of three,
but the total size of the TLV would be eight octets). Nested TLVs are
also 32-bit aligned. Unrecognized types are ignored.
This memo defines TLV Types 1 through 8. See the IANA Considerations
section for allocation of new Types.
The MPLS Label LSA may be originated by any Traffic Engineering capable router in an OSPF
domain.
The router may advertise a single label
binding or a block of label bindings. For single label binding
advertisement a router needs to provide at least a single
'nexthop style' anchor.
The protocol supports more than one 'nexthop style' anchor
to be attached to a Label binding, which results into a simple path
description language. In analogy to RSVP the terminology for this is
called an 'Explicit Route Object' (ERO).
Since ERO style path notation allows to anchor label bindings to
to both link and node IP addresses any label switched path,
can be described. Furthermore also Label Bindings from other protocols
can get easily re-advertised.
An LSA contains one or more TLVs, describing properties of the
advertised MPLS label.
The following TLV extensions may be shared in both OSPV2 and OSPFv3.
Passing an IP address of the other address family (IPv4 in OPSFv3
or IPv6 in OSPFv2)
is possible as the information carried are related describing the hops
along a path. The receiver of this information is a protocol agnostic
path computation module.
All 'ERO' information represents an ordered set
which describes the segments of a label-switched path. The last
ERO TLV describes the segment closest to the egress point of the
LSP. Contrary the first ERO TLV describes the first segment
of a label switched path. If a router extends or stitches a label
switched path it MUST prepend the new segments path information to the
ERO list.
The IPv4 ERO TLV (Type 1) describes a path segment using IPv4 Prefix style of encoding.
Its appearance and semantics have been borrowed from
Section 4.3.3.2.
the 'IPv4 Address' is treated as a prefix based on
the prefix length value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
The 'Prefix Length' field contains the length of the prefix in bits.
The 'L' bit in the TLV is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The IPv6 ERO TLV (Type 2) describes a path segment using IPv6 Prefix style of encoding.
Its appearance and semantics have been borrowed from
Section 4.3.3.2.
the 'IPv6 Address' is treated as a prefix based on
the prefix length value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
The 'Prefix Length' field contains the length of the prefix in bits.
The 'L' bit in the TLV is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The appearance and semantics of the 'Unnumbered Interface ID'
have been borrowed from Section 4.
The Unnumbered Interface-ID ERO TLV (Type 9)
describes a path segment that spans over an unnumbered
interface. Unnumbered interfaces are referenced using the
interface index. Interface indices are assigned local to
the router and therefore not unique within a domain. All elements
in an ERO path need to be unique within a domain and hence need
to be disambiguated using a domain unique Router-ID.
The 'Router-ID' field contains the router ID of the router
which has assigned the 'Interface ID' field. Its purpose is to
disambiguate the 'Interface ID' field from other routers
in the domain.The 'Interface ID' is the identifier assigned to the link
by the router specified by the router ID.
The 'L' bit in the TLV is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The IPv4 Bypass ERO TLV (Type 3) describes a Bypass LSP path segment
using IPv4 Prefix style of encoding.
Its appearance and semantics have been borrowed from
Section 4.3.3.2.
The 'Prefix Length' field contains the length of the prefix in bits.
The 'L' bit in the TLV is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The IPv6 ERO TLV (Type 4) describes a Bypass LSP path segment
using IPv6 Prefix style of encoding.
Its appearance and semantics have been borrowed from
Section 4.3.3.3.
The 'Prefix Length' field contains the length of the prefix in bits.
The 'L' bit in the TLV is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'
The appearance and semantics of the 'Unnumbered Interface ID'
have been borrowed from Section 4.
The Unnumbered Interface-ID Bypass ERO TLV (Type 10)
describes a Bypass path segment that spans over an unnumbered
interface. Unnumbered interfaces are referenced using the
interface index. Interface indices are assigned local to
the router and therefore not unique within a domain. All elements
in an ERO path need to be unique within a domain and hence need
to be disambiguated using a domain unique Router-ID.
The 'Router-ID' field contains the router ID of the router
which has assigned the 'Interface ID' field. Its purpose is to
disambiguate the 'Interface ID' field from other routers
in the domain.The 'Interface ID' is the identifier assigned to the link
by the router specified by the router ID.
The 'L' bit in the TLV is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The Flags TLV (Type 5) describes Flags for further MPLS LSA treatment.
Up/Down 'U' Bit: A router may flood MPLS label information across area boundaries.
In order to prevent flooding loops, a router will Set the Up/Down (U-Bit)
when propagating MPLS labels from Area 0 to a non-zero Area.
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The 'All Router Block' TLV (Type 6) denominates the label block size of
an MPLS Label advertisement and its semantics to connect to all routers in
a given OSPF domain using a local assigned
label range. Note that the actual mapping of a router within the label range
is done using the TLVs described in
and . Since generation of
an IPv4 or IPv6 Map TLV is a local policy decision, it might be the case
that connectivity is provided not to 'All' but rather a subset of 'All'
routers. Keeping policy decisions aside, for simplicity reasons,
assume that All Routers in a domain do generate either the
'All Router ID IPv4 Map' or
'All Router ID IPv6 Map' TLVs and therefore all routers
desire construction of a Label switched path from every source router
in the network.
The basic concept of using label blocks to provide connectivity
to a set of routers has been borrowed from
which allows to advertise labels from multiple end-points using a single control-plane
message. The difference to is that rather than advertising
where a particular packet came from (=source semantics), destination semantics
(where a particular packet will be going to) is advertised.
Along with each label block a router advertises one for more 'IDs'.
The 'ID' must be unique within a given domain.
The 'ID' serves as ordinal to determine the actual label value
inside the set of all advertised label ranges of a given router.
A receiving router uses the ordinal to determine the actual label value
in order to construct forwarding state to
a particular destination router.
The 'ID' is separately advertised using the TLVs described in
and
.
The ability to advertise more than one label block eases operational
procedures for increasing the number of supported routers within a domain.
For example consider a given domain has got support for <M> routers
and runs out of ID space.
It simply advertises one more label block to cover additional
ordinals outside the range of the first label block.
An example of label-block expansion is described in more detail in
The 'Block Size' value contains the size of the label advertisement.
The 'value determines the amount of reachable router endpoints
within a given Label block.
It MUST contain a value greater or equal than two.
Note that the label base is inferred from the LSA-ID in the LSA header.
For example if a router wants to advertise a label range of 5000-5099 then
it would need to generate a LSA-ID of 5000 (= 0.0.19.136) and a Block
Size of 100.
The 'Algo' value denominates the path computation algorithm in order
to calculate the forwarding topology. The basic SPF algorithm
has an assigned 'Algo' code point of zero. The purpose of the
'Algo' field is to extend the notion of Label Block Signaling
to arbitrary algorithms like for example 'MRT'
(.
Advertised Label Blocks with an unknown, unsupported or non-configured
algorithm MUST be silently ignored.
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The 'Topology-ID' field contains the Multi Topology ID
() for which the advertised Label Block
does apply. The basic IPv4 unicast Topology has an assigned
'Topology-ID' code point of zero.
Advertised Label Blocks with an unknown, unsupported or non-configured
Topology-ID MUST be silently ignored.
An LSA containing the 'All Router Block' TLV MUST only contain
the Flags TLV (, the
'All Router IPv4 Map' TLV
()
or the 'All Router IPv6 Map' TLV
().
The 'All Router ID IPv4 Map' TLV (Type 7) maps an 'ID' to a given
stable transport IPv4 address. Its purpose is to associate
a given transport IPv4 IP address to the ordinal inside a label range
as described in .
A router MAY advertise more than one 'ID' to 'IPv4 address'
mapping pair, in case it has more than one stable transport
IPv4 address.
The 'IPv4 address' contains stable IPv4 transport address of a given router.
The 'ID' contains the ordinal value of an advertising router inside the
set of all advertised label blocks of a given router.
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The 'All Router ID IPv6 Map' TLV (Type 8) maps an 'ID' to a given
stable transport IPv6 address. Its purpose is to associate
a given transport IPv6 IP address to the ordinal inside a label range
as described in .
A router MAY advertise more than one 'ID' to 'IPv6 address'
mapping pair, in case it has more than one stable transport
IPv6 address.
The 'IPv6 address' contains the stable IPv6 transport address
of a given router.
The 'ID' contains the ordinal value of an advertising router inside the
set of all advertised label blocks of a given router.
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
The following topology and IP addresses shall be used throughout
the Label advertisement examples.
R1: 192.168.1.1R2: 192.168.1.2R3: 192.168.1.3R4: 192.168.1.4R5: 192.168.1.5R6: 192.168.1.6R7: 192.168.1.7R1 to R2 link: 10.0.0.1, 10.0.0.2R1 to R4 link: 10.0.0.9, 10.0.0.10R2 to R3 link #1: 10.0.0.3, 10.0.0.4R2 to R3 link #2: 10.0.0.5, 10.0.0.6R2 to R5 link: 10.0.0.7, 10.0.0.8R3 to R6 link: 10.0.0.13, 10.0.0.14R3 to R7 link: 10.0.0.15, 10.0.0.16R4 to R5 link: 10.0.0.19, 10.0.0.20R5 to R6 link: 10.0.0.11, 10.0.0.12R6 to R7 link: 10.0.0.17, 10.0.0.18
The IGP link metrics are displayed in the middle of the link.
All of them are assumed to be bi-directional.
If R1 would advertise a label <N> bound to a one-hop LSP
from R1 to R2 it would encode as follows:LSA 149, LSA-ID <N>:
IPv4 Prefix ERO TLV: 192.168.1.2/32, StrictIf R2 would advertise a label <N>bound to a one-hop LSP
from R2 to R3, using the link #2 it would encode as followsLSA 149, LSA-ID <N>:
IPv4 Prefix ERO TLV: 10.0.0.6/32, StrictIf R3 would advertise a label <N> bound to a one-hop LSP
from R3 to R7 (which is outside of the IGP domain),
it would encode as follows:LSA 149, LSA-ID <N>:
IPv4 Prefix ERO TLV: 192.168.1.7/32, Strict
As you can see the representation of an MPLS label crossing
an external link is identical as an internal link
.
Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link #1, R6):If R2 would advertise a label <N> bound to the RSVP LSP named 'R2-to-R6',
it would encode as followsLSA 149, LSA-ID <N>:
IPv4 Prefix ERO TLV: 10.0.0.4/32, StrictIPv4 Prefix ERO TLV: 192.168.1.6/32, StrictConsider R2 that creates a LDP label binding for FEC 172.16.0.0./12
using label <N>.If R2 would re-advertise this label binding in OSPF it would encode as followsLSA 149, LSA-ID <N>:
IPv4 Prefix ERO TLV: 172.16.0.0/12, LooseConsider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6}Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3}R2 encodes its two paths to R6 as follows:LSA 149, LSA-ID <N1>:
IPv4 Prefix ERO TLV: 192.168.1.3, LooseIPv4 Prefix ERO TLV: 192.168.1.6, LooseFlags TLV: DownLSA 149, LSA-ID <N2>:
IPv4 Prefix ERO TLV: 192.168.1.5, LooseIPv4 Prefix ERO TLV: 192.168.1.6, LooseFlags TLV: DownR5 encodes its two paths to R3 as follows:LSA 149, LSA-ID <N1>:
IPv4 Prefix ERO TLV: 192.168.1.2, LooseIPv4 Prefix ERO TLV: 192.168.1.3, LooseFlags TLV: DownLSA 149, LSA-ID <N2>:
IPv4 Prefix ERO TLV: 192.168.1.6, LooseIPv4 Prefix ERO TLV: 192.168.1.3, LooseFlags TLV: Down
A receiving non-backbone router does see now all 4 paths and may decide
to load-balance across all or a subset of them.
All routers within a given area MUST advertise their Label Blocks
along with an 'ID'.
If R2 would advertise a label block <N1> with a size of 10,
declaring SPT label forwarding support to all routers within a given domain,
it would encode as follows:LSA 149, LSA-ID <N1>:
All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0All Router ID IPv4 Map TLV: ID 2, 192.168.1.2If R3 would advertise a label block <N2> with a size of 10,
declaring SPT label forwarding support to all routers within a given domain,
it would encode as follows:LSA 149, LSA-ID <N2>:
All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0All Router ID IPv4 Map TLV: ID 3, 192.168.1.3If R5 would advertise a label block <N3> with a size of 10,
declaring SPT label forwarding support to all routers within a given domain,
it would encode as follows:LSA 149, LSA-ID <N3>:
All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0All Router ID IPv4 Map TLV: ID 5, 192.168.1.5If R6 would advertise a label block <N4> with a size of 10,
declaring SPT label forwarding support to all routers within a given domain,
it would encode as follows:LSA 149, LSA-ID <N4>:
All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0All Router ID IPv4 Map TLV: ID 6, 192.168.1.6
Consider now R2 constructing a SPT label for R6. R2s SPT to R6 is
{R2, IP4, R3, R6}. R2 first determines if its downstream router
(R3) has advertised a label-block. Since R3 has advertised a label block
'N2' and it has received R6 'ID' of 6 it will be picking the 6th label
value inside the advertised range of its downstream neighbor.
Specifically R2 MUST be program a
MPLS SWAP for its own label range Label(N1+6) to Label(N2+6),
NH 10.0.0.4 into its MPLS transit RIB.
Furthermore R2 MAY program a MPLS PUSH operation for IP 192.168.1.6 to
Label (N2+6), NH 10.0.0.4 into its IPv4 tunnel RIB.
Next walk down to R3, which is
the next router on the SPT tree towards R6.
R3s SPT to R6 is {R3, R6}.
R3 determines if its downstream router
(R6) has advertised a label-block. Since R6 has advertised a label block
'N4' and it has received R6 'ID' of 6 it will be picking the 6th label
value inside the advertised range of its downstream neighbor.
Since R3 is the penultimate router to R6 it MUST program a
MPLS POP for its own label range Label(N2+6) NH 10.0.0.14 into
its MPLS transit RIB.
Furthermore R3 MAY program a MPLS NOP for IP 192.168.1.6,
NH 10.0.0.14 into its IPv4 tunnel RIB.
All routers within a given area MUST advertise their Label Blocks
along with an 'ID'. Now assume that the initial label block
size assignment is too small to support all routers which
generate an ordinal within an IGP domain.
Consider the seven routers in ,
and assume that R7 advertises a new ID '15' using an
'All Router ID Map' TLV. ID '15' is outside of the range
of '10' as per the previous example in
.
Now all the routers in an IGP domain need to advertise one
more label block in order to map the ID '15' to an actual
label value.
All routers would advertise in addition to their
label block <N> with a size of 10, a second label block <N2>
with a size sufficient enough, that the new ordinal can get covered.
In this example the same block size 10 is used also for the
second label block. For example router R2 would advertise the
following label bindings.
LSA 149: LSA-ID <N1>:
All Router Block TLV: Block Size 10, Algo 0, Topology 0All Router ID IPv4 Map TLV: ID 2, 192.168.1.2LSA 149: LSA-ID <N2>:
All Router Block TLV: Block Size 10, Algo 0, Topology 0
Now the upstream router can map the new ID of R7 to an
actual label value, as ID '15' corresponds to the 5th label
inside the second Label block.
Propagation of a MPLS LSPs and MPLS Block LSPs across
an area boundary is a local policy decision.
If local policy dictates that a given ABR router needs to
re-advertise a MPLS LSPs from one area to another then it MUST
allocate a new label and program its label forwarding table to connect
the new label to the path in the respective other area. Depending on
how to reach the re-advertised LSP, this is typically done using
a MPLS 'SWAP' or 'SWAP/PUSH' data plane operation.
If local policy dictates that a given ABR router needs to
re-advertise MPLS LSPs from one area to another then it
must prepend its "Traffic-Engineering-ID" as a loose hop in the
Prefix ERO TLV list. Furthermore it MUST append the Flags TLV and
set the 'Down' Bit.
If local policy dictates that a given ABR router advertises
its 'All Router Block' into another area, then it also
MUST re-advertise all known 'ID' ordinals (again gated by policy)
to the respective other area. Without knowledge of all 'ID's
in the network no router is able to construct SPT label switched paths.
Furthermore an ABR MUST append the Flags TLV and
set the 'Down' Bit for all re-advertised 'CE' IDs.
Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge
for their useful comments.
This documents request allocation for one common OSPFv2 and OSPFv3
LSA Type and TLVs contained within.
LSA TypeTLVTLV Type#Occurence149>=0IPv4 Prefix ERO1>=0IPv6 Prefix ERO2>=0Unnumbered Interface ID ERO9>=0IPv4 Prefix Bypass ERO3>=0IPv6 Prefix Bypass ERO4>=0Unnumbered Bypass Interface ID ERO10>=0Flags50,1All Router Block6>=0All Router ID IPv4 Map7>=0All Router ID IPv6 Map8>=0
The MPLS Label LSA requires a new sub-registry, with a starting TLV
value of 1, and managed by IETF consensus.
This document does not introduce any change in terms of OSPF
security. It simply proposes to flood MPLS label information via the IGP.
All existing procedures to ensure message integrity do apply here.