01-26-2019 06:49 AM
In above topology area 1 and area 0 is SR-enabled but area 2 is LDP only. I leaking both PE's loopbck IP into area 1/2. I am using mapping server to assign and advertise prefix-sid for 10.10.10.10/32 ( Loop back of PE-10). From lab experience my conclusion is as follows.
Am I right ?
where to Place Mapping server ? --- mapping server in each level/area ?
If we have multiple mapping server with different prefix-sid mapping which will one be preferred
I have documented the above lab. Attaching it for reference
Solved! Go to Solution.
01-26-2019 08:56 AM - edited 01-26-2019 09:42 AM
Hi Samrjit,
Mapping Server or normal router prefix to SID mappings should propagate through out the ISIS domain across multiple levels.
In case of multiple mapping servers highest preference value (0-255) is preferred. Mapping server can be placed anywhere in the IGP SR domain.
check if you have the domain-wide keyword
segment-routing prefix-sid-map advertise-local [domain-wide]
I have pasted reference text from relevent IETF drafts. Can you test this in your lab?
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-15#page-11
3.2.3. Interoperability of Multiple SRMSes and Prefix-SID advertisements
In the case of SR/LDP interoperability through the use of a SRMS, mappings are advertised by one or more SRMS. SRMS function is implemented in the link-state protocol (such as IS- IS and OSPF). Link-state protocols allow propagation of updates across area boundaries and therefore SRMS advertisements are propagated through the usual inter-area advertisement procedures in link-state protocols. Multiple SRMSs can be provisioned in a network for redundancy. Moreover, a preference mechanism may also be used among SRMSs so to deploy a primary/secondary SRMS scheme allowing controlled modification or migration of SIDs. The content of SRMS advertisement (i.e.: mappings) are a matter of local policy determined by the operator. When multiple SRMSs are active, it is necessary that the information (mappings) advertised by the different SRMSs is aligned and consistent. The following mechanism is applied to determine the preference of SRMS advertisements: If a node acts as an SRMS, it MAY advertise a preference to be associated with all SRMS SID advertisements sent by that node. The means of advertising the preference is defined in the protocol specific drafts e.g.,[I-D.ietf-isis-segment-routing-extensions] , [I-D.ietf-ospf-segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The preference value is an unsigned 8 bit integer with the following properties: 0 - Reserved value indicating advertisements from that node MUST NOT be used. 1 - 255 Preference value (255 is most preferred) Advertisement of a preference value is optional. Nodes which do not advertise a preference value are assigned a preference value of 128.
====================
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/?include_text=1
2.1.2. Prefix-SID Propagation
The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV
gets propagated across level boundaries.
The level-1-2 router that propagates the Prefix-SID sub-TLV between
levels MUST set the R-flag.
If the Prefix-SID contains a global index (L and V flags unset) and
it is propagated as such (with L and V flags unset), the value of the
index MUST be preserved when propagated between levels.
The level-1-2 router that propagates the Prefix-SID sub-TLV between
levels MAY change the setting of the L and V flags in case a local
label value is encoded in the Prefix-SID instead of the received
value.
2.4. SID/Label Binding TLV
The SID/Label Binding TLV MAY be originated by any router in an IS-IS
domain.
<SNIP>
S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across
the entire routing domain. If the S flag is not set, the SID/
Label Binding TLV MUST NOT be leaked between levels. This bit
MUST NOT be altered during the TLV leaking.
D-Flag: when the SID/Label Binding TLV is leaked from level-2 to
level-1, the D bit MUST be set. Otherwise, this bit MUST be
clear. SID/Label Binding TLVs with the D bit set MUST NOT be
leaked from level-1 to level-2. This is to prevent TLV looping
across levels.
A-Flag: Attached flag. The originator of the SID/Label Binding
TLV MAY set the A bit in order to signal that the prefixes and
SIDs advertised in the SID/Label Binding TLV are directly
connected to their originators. The mechanisms through which the
originator of the SID/Label Binding TLV can figure out if a prefix
is attached or not are outside the scope of this document (e.g.:
through explicit configuration). If the Binding TLV is leaked to
other areas/levels the A-flag MUST be cleared.
2.4.4. Mapping Server Prefix-SID
The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1
and contains the SID/index/label value associated with the prefix and
range. The Prefix-SID SubTLV MUST be present in the SID/Label
Binding TLV unless the M-flag is set in the Flags field of the parent
TLV.
A node receiving an SRMS entry for a prefix MUST check the existence
of such prefix in its link-state database prior to consider and use
the associated SID.
01-26-2019 08:56 AM - edited 01-26-2019 09:42 AM
Hi Samrjit,
Mapping Server or normal router prefix to SID mappings should propagate through out the ISIS domain across multiple levels.
In case of multiple mapping servers highest preference value (0-255) is preferred. Mapping server can be placed anywhere in the IGP SR domain.
check if you have the domain-wide keyword
segment-routing prefix-sid-map advertise-local [domain-wide]
I have pasted reference text from relevent IETF drafts. Can you test this in your lab?
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-15#page-11
3.2.3. Interoperability of Multiple SRMSes and Prefix-SID advertisements
In the case of SR/LDP interoperability through the use of a SRMS, mappings are advertised by one or more SRMS. SRMS function is implemented in the link-state protocol (such as IS- IS and OSPF). Link-state protocols allow propagation of updates across area boundaries and therefore SRMS advertisements are propagated through the usual inter-area advertisement procedures in link-state protocols. Multiple SRMSs can be provisioned in a network for redundancy. Moreover, a preference mechanism may also be used among SRMSs so to deploy a primary/secondary SRMS scheme allowing controlled modification or migration of SIDs. The content of SRMS advertisement (i.e.: mappings) are a matter of local policy determined by the operator. When multiple SRMSs are active, it is necessary that the information (mappings) advertised by the different SRMSs is aligned and consistent. The following mechanism is applied to determine the preference of SRMS advertisements: If a node acts as an SRMS, it MAY advertise a preference to be associated with all SRMS SID advertisements sent by that node. The means of advertising the preference is defined in the protocol specific drafts e.g.,[I-D.ietf-isis-segment-routing-extensions] , [I-D.ietf-ospf-segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The preference value is an unsigned 8 bit integer with the following properties: 0 - Reserved value indicating advertisements from that node MUST NOT be used. 1 - 255 Preference value (255 is most preferred) Advertisement of a preference value is optional. Nodes which do not advertise a preference value are assigned a preference value of 128.
====================
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/?include_text=1
2.1.2. Prefix-SID Propagation
The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV
gets propagated across level boundaries.
The level-1-2 router that propagates the Prefix-SID sub-TLV between
levels MUST set the R-flag.
If the Prefix-SID contains a global index (L and V flags unset) and
it is propagated as such (with L and V flags unset), the value of the
index MUST be preserved when propagated between levels.
The level-1-2 router that propagates the Prefix-SID sub-TLV between
levels MAY change the setting of the L and V flags in case a local
label value is encoded in the Prefix-SID instead of the received
value.
2.4. SID/Label Binding TLV
The SID/Label Binding TLV MAY be originated by any router in an IS-IS
domain.
<SNIP>
S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across
the entire routing domain. If the S flag is not set, the SID/
Label Binding TLV MUST NOT be leaked between levels. This bit
MUST NOT be altered during the TLV leaking.
D-Flag: when the SID/Label Binding TLV is leaked from level-2 to
level-1, the D bit MUST be set. Otherwise, this bit MUST be
clear. SID/Label Binding TLVs with the D bit set MUST NOT be
leaked from level-1 to level-2. This is to prevent TLV looping
across levels.
A-Flag: Attached flag. The originator of the SID/Label Binding
TLV MAY set the A bit in order to signal that the prefixes and
SIDs advertised in the SID/Label Binding TLV are directly
connected to their originators. The mechanisms through which the
originator of the SID/Label Binding TLV can figure out if a prefix
is attached or not are outside the scope of this document (e.g.:
through explicit configuration). If the Binding TLV is leaked to
other areas/levels the A-flag MUST be cleared.
2.4.4. Mapping Server Prefix-SID
The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1
and contains the SID/index/label value associated with the prefix and
range. The Prefix-SID SubTLV MUST be present in the SID/Label
Binding TLV unless the M-flag is set in the Flags field of the parent
TLV.
A node receiving an SRMS entry for a prefix MUST check the existence
of such prefix in its link-state database prior to consider and use
the associated SID.
03-20-2019 11:45 AM
The domain-wide keyword is available in XE but what about XR? I don't see an equivalent command
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide