[spring] clarification of text in draft-ietf-spring-segment-routing-09

Chris Bowers <cbowers@juniper.net> Wed, 03 August 2016 14:28 UTC

From: Chris Bowers <cbowers@juniper.net>
To: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: clarification of text in draft-ietf-spring-segment-routing-09
Thread-Index: AdHtj9OWTl/X2uSrQPadAdVrICCUdw==
Date: Wed, 03 Aug 2016 14:24:19 +0000
Message-ID: <MWHPR05MB2829008244E4197C6F3ACB89A9060@MWHPR05MB2829.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2016 14:24:19.6017 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2830
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/rDV9aVfN8PBB2lyza3rI0laLIrQ>
Subject: [spring] clarification of text in draft-ietf-spring-segment-routing-09
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2016 14:28:43 -0000

SPRING WG,

The following paragraph in section 3.2.1 of draft-ietf-spring-segment-routing-09 is confusing.

The ingress node of an SR domain validates that the path to a prefix,
advertised with a given algorithm, includes nodes all supporting the
advertised algorithm. In other words, when computing paths for a
given algorithm, the transit nodes MUST compute the algorithm X on
the IGP topology, regardless of the support of the algorithm X by the
nodes in that topology. As a consequence, if a node on the path does
not support algorithm X, the IGP-Prefix segment will be interrupted
and will drop packet on that node. It's the responsibility of the
ingress node using a segment to check that all downstream nodes
support the algorithm of the segment.

I interpret the first, third, and fourth sentences in this paragraph
as saying that an ingress node should make sure that transit nodes on a path
install transit forwarding entries for prefix-SIDs for a given algorithm by looking that
the SR-Algorithm (sub)-TLV advertised by the transit nodes before sending traffic on that path.

However, the second sentence in the paragraph confuses this interpretation.

"In other words, when computing paths for a
given algorithm, the transit nodes MUST compute the algorithm X on
the IGP topology, regardless of the support of the algorithm X by the
nodes in that topology."

This sentence could be interpreted as saying that transit nodes must compute
all algorithms advertised by any node in the topology, even if the transit node doesn't
support the algorithm. This sentence doesn't make sense to me.

A simple solution would be to delete this second sentence. However,
other clarifying text would be another solution.

Thanks,
Chris

[spring] clarification of text in draft-ietf-spri… Chris Bowers
Re: [spring] clarification of text in draft-ietf-… Chris Bowers
Re: [spring] clarification of text in draft-ietf-… Stefano Previdi (sprevidi)
Re: [spring] clarification of text in draft-ietf-… Chris Bowers
Re: [spring] clarification of text in draft-ietf-… Stefano Previdi (sprevidi)