draft-ietf-ospf-segment-routing-extensions-14.txt   draft-ietf-ospf-segment-routing-extensions-15.txt 
Open Shortest Path First IGP P. Psenak, Ed. Open Shortest Path First IGP P. Psenak, Ed.
Internet-Draft S. Previdi, Ed. Internet-Draft S. Previdi, Ed.
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: November 5, 2017 Cisco Systems, Inc. Expires: November 23, 2017 Cisco Systems, Inc.
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
R. Shakir R. Shakir
Google, Inc. Google, Inc.
W. Henderickx W. Henderickx
Nokia Nokia
J. Tantsura J. Tantsura
Individual Individual
May 4, 2017 May 22, 2017
OSPF Extensions for Segment Routing OSPF Extensions for Segment Routing
draft-ietf-ospf-segment-routing-extensions-14 draft-ietf-ospf-segment-routing-extensions-15
Abstract Abstract
Segment Routing (SR) allows a flexible definition of end-to-end paths Segment Routing (SR) allows a flexible definition of end-to-end paths
within IGP topologies by encoding paths as sequences of topological within IGP topologies by encoding paths as sequences of topological
sub-paths, called "segments". These segments are advertised by the sub-paths, called "segments". These segments are advertised by the
link-state routing protocols (IS-IS and OSPF). link-state routing protocols (IS-IS and OSPF).
This draft describes the OSPF extensions required for Segment This draft describes the OSPF extensions required for Segment
Routing. Routing.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 5, 2017. This Internet-Draft will expire on November 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 14, line 17 skipping to change at page 14, line 17
original order when advertising prefix-SIDs to other areas. This original order when advertising prefix-SIDs to other areas. This
allows implementations that only support a single Prefix-SID to have allows implementations that only support a single Prefix-SID to have
a consistent view across areas. a consistent view across areas.
When calculating the outgoing label for the prefix, the router MUST When calculating the outgoing label for the prefix, the router MUST
take into account the E and P flags advertised by the next-hop router take into account the E and P flags advertised by the next-hop router
if that router advertised the SID for the prefix. This MUST be done if that router advertised the SID for the prefix. This MUST be done
regardless of whether the next-hop router contributes to the best regardless of whether the next-hop router contributes to the best
path to the prefix. path to the prefix.
The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter- The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for
area prefixes that are originated by the ABR based on intra-area or Prefix-SIDs allocated to inter-area prefixes that are originated by
inter-area reachability between areas. When the inter-area prefix is the ABR based on intra-area or inter-area reachability between areas,
generated based on a prefix which is directly attached to the ABR, unless the advertised prefix is directly attached to the ABR.
the NP-Flag SHOULD NOT be set.
The NP-Flag (No-PHP) MUST be be set for Prefix-SIDs allocated to The NP-Flag (No-PHP) MUST be be set and the E-flag MUST be clear for
redistributed prefixes, unless the redistributed prefix is directly Prefix-SIDs allocated to redistributed prefixes, unless the
attached to the ASBR, in which case the NP-flag SHOULD NOT be set. redistributed prefix is directly attached to the ASBR.
If the NP-Flag is not set, then any upstream neighbor of the Prefix- If the NP-Flag is not set, then any upstream neighbor of the Prefix-
SID originator MUST pop the Prefix-SID. This is equivalent to the SID originator MUST pop the Prefix-SID. This is equivalent to the
penultimate hop popping mechanism used in the MPLS dataplane. In penultimate hop popping mechanism used in the MPLS dataplane. In
such case, MPLS EXP bits of the Prefix-SID are not preserved for the such case, MPLS EXP bits of the Prefix-SID are not preserved for the
final destination (the Prefix-SID being removed). If the NP-flag is final destination (the Prefix-SID being removed). If the NP-flag is
not set then the received E-flag is ignored. not set then the received E-flag is ignored.
If the NP-flag is set then: If the NP-flag is set then:
skipping to change at page 29, line 30 skipping to change at page 29, line 30
Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented
by a star topology where the Designated Router (DR) is the central by a star topology where the Designated Router (DR) is the central
point to which all other routers on the broadcast, NBMA, or hybrid point to which all other routers on the broadcast, NBMA, or hybrid
network connect. As a result, routers on the broadcast, NBMA, or network connect. As a result, routers on the broadcast, NBMA, or
hybrid network advertise only their adjacency to the DR. Routers hybrid network advertise only their adjacency to the DR. Routers
that do not act as DR do not form or advertise adjacencies with each that do not act as DR do not form or advertise adjacencies with each
other. They do, however, maintain 2-Way adjacency state with each other. They do, however, maintain 2-Way adjacency state with each
other and are directly reachable. other and are directly reachable.
When Segment Routing is used, each router on the broadcast, NBMSA, or When Segment Routing is used, each router on the broadcast, NBMA, or
hybrid network MAY advertise the Adj-SID for its adjacency to the DR hybrid network MAY advertise the Adj-SID for its adjacency to the DR
using the Adj-SID Sub-TLV as described in Section 7.1. using the Adj-SID Sub-TLV as described in Section 7.1.
SR capable routers MAY also advertise a LAN-Adj-SID for other SR capable routers MAY also advertise a LAN-Adj-SID for other
neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid
network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2. network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2.
9. IANA Considerations 9. IANA Considerations
This specification updates several existing OSPF registries. This specification updates several existing OSPF registries.
 End of changes. 7 change blocks. 
13 lines changed or deleted 12 lines changed or added

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