< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/