Subject: Questions / comments regarding draft-voyer-6man-extension-header-insertion (was: Proposed revised Extension Header text for rfc2460bis)

From: "C. M. Heard" <[email-masked]>
Date: Wed, 3 May 2017 11:23:24 -0700

Gentlemen,

Following the cue from our AD, I want to pose some questions and comments
regarding draft-voyer-6man-extension-header-insertion that were prompted
by some comments in an earlier post, in the hope doing so will help advance
a constructive discussion on an eventual update for 2460bis that suits the
needs of the segment routing community.

On Mon, 1 May 2017 03:17:16 -0400 Robert Raszuk wrote:
> If you would follow SR-MPLS you would realize that MPLS label carries an
> embedded function. Exactly like SID in SRH.

Two points that had escaped me, and possibly others participating in this
discussion, are that:

- An SRv6 Segment ID (SID) is an IPv6 address assigned to a node, not
necessarily one associated with one of its physical interfaces, that
identifies an SRV6 segment.

- When a packet whose Destination Address (DA) is an SRv6 SID arrives at
the node that "owns" that address, it triggers special processing (the
"embedded function" that you mention above). That would include forwarding
instructions and possibly instructions on how to modify an existing segment
routing header in case of fast reroute.

That much is now clear to me, but only after looking at

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#section-2.2
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.1.3

Listing these in draft-voyer-6man-extension-header-insertion as
required prerequisite reading would, I think, be helpful to the
target audience -- which consists primarily of folks from outside
the segment routing community.

It is less clear to me under what circumstances one would wish to
insert a segment routing header at a transit node (aka intermediate
node -- i.e., a node other than the one specified in the DA of the
packet in question) when one did not previously exist. Thus, as a
clarification to draft-voyer-6man-extension-header-insertion:

- In Section 2, please specify in the following step

   o  Node 1 originates a packet P1 destined to 9 (SA=1, DA=9).

whether or not the packet has a segment routing header; if so, specify
the path (which would presumably include node 2); if not, explain how
the packet is to be routed, and explain how node 2 decides to insert
a segment routing header.

- In Section 3, provide the same clarification if not already covered by
the change to Section 2.

> Moreover with the overhead of signaling required to established an LSP in
> MPLS case transit nodes no matter if they are within domain or beyond domain
> DO NOT NEED to change any single bit in their current forwarding paradigm.
> SR functions are executed only at the designated nodes which are able to
> perform the desired forwarding behaviour.

If this is also true for the IPv6 data plane, I would not expect a transit
node to need to insert a segment routing header, irrespective of whether
it is part of the SR domain or not. If this is totally off base, it would
be good for draft-voyer-6man-extension-header-insertion to explain why.

> This entire discussion that maybe we will bless SRv6 in closed domains just
> does not get the fundamental point that transit nodes regardless on how many
> SRH are in the IPv6 packet will work just fine. Of course there is MTU
> concern ... but this concern is also with MPLS stacking or for that matter
> with any encapsulation. And we do know today how to effectively solve it
> when/where needed.

I totally get that transit nodes (i.e., nodes that are not specified by the
DA of the packet during any hop) should not need to change their behavior
and all and  should work just fine irrespective of whether the segment
routing header is present or not. That is what 2460 and the current
incarnation of 2460bis mandate. [That is also widely violated -- packets
with unknown extension headers are often dropped in practice -- but the
hope is that in time adoption of RFC 7045 will help the situation.]

But as part of dealing with the MTU problem, one of the prerequisites for
correct operation is that the DA of packet that contains a segment routing
header MUST point to a node that is able to correctly deal with Packet Too
Big ICMPv6 messages. Actually, that is true for any ICMP error message
related to the SRH. That is a manageable problem if SRH is added only by
the originating node or after encapsulation by a border router, but it is
less clear how it is managed of SRH is inserted in flight. So:

- Add text to draft-voyer-6man-extension-header-insertion explaining
how it is ensured that ICMP messages for a packet containing a segment
routing header get back to a node that understands what they mean. If
SRH can be inserted (as opposed to modified) by an intermediate note,
that is a non-trivial matter

> It get's even worse if you (like some of this WG members) now require to
> encapsulate packets in additional v6 header before SRH is inserted - makes
> zero sense ! Just please kindly observe that if you do the encap the dst
> address can be anywhere in the Internet .. no encap code mandates that dst
> must be in your IGP. So packets do escape ASes .. BGP in fact was explicitly
> created to help/assist them to escape.

I think there is a problem here by imprecise use of language. The quoted
text a couple of paragraphs above says "regardless on how many SRH are in
the IPv6 packet." However, according to

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#section-3.2

the SRH should appear at most once in a packet. Now, the MPLS example in

https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-00#section-2.1

discusses adding labels, which would be analogous to adding individual
segments to the segment list in the SRH, not to adding another SRH. Is
that what is actually being discussed?

Based on the existing documentation, I get why there is a desire to modify
the segment list of an SRH without adding another layer of encapsulation.
Doing so would violate the expectation in RFC 4302  (AH) that the network
will not change the length of an extension header, meaning that SRH could
not be used in conjunction with AH. That is something else that
draft-voyer-6man-extension-header-insertion should mention.

What I don't get is why there is a desire for a node to insert an SRH
without encapsulation when none was there to begin with. If that is
really desired, draft-voyer-6man-extension-header-insertion needs to
explain why.

> I think perhaps a dedicated interim meeting should be setup just to discuss
> it and understand it well before we proceed with any further spec
> clarifications or extensions.

Sure. But that should not stop 2460bis. It's supposed to be IS. Any new
extension to support the SR community's requirements would come in at PS.
An enhanced version of draft-voyer-6man-extension-header-insertion will
help move that process forward.

Thanks & regards,

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 3 May 2017 17:18:37 -0700

I see an embarrassing typo in my previous message.

> less clear how it is managed of SRH is inserted in flight. So:

The above should say SA (source address) where it says DA.

Sorry about that.

//cmh

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 5 May 2017 21:14:33 +0000

Hello Mike,

See inline.

On 2017-05-03, 2:23 PM, "C. M. Heard" <[email-masked]> wrote:

    Gentlemen,

    

Correct.

Correct.

Agree and will add text and references.

Note that draft-voyer-6man-extension-header-insertion has been written with the purpose to illustrate _one_ evident use-case where header insertion is useful, not harmful and very beneficial. The intent of the draft is not to come with a complete set of solutions on how you can insert and update a source route path for a given packet.

The first step towards header insertion, is to clearly document the practical, operational use-case where it is required (used) and safe.

 
As illustrated in the draft, the statement "Node 1 originates a packet P1 destined to 9 (SA=1, DA=9)” refers to the action the ingress node of the source domain consisting of encapsulating the incoming packet (i.e.: the packet entering in the source domain) into an outer header with SA=himself (i.e., node 1) and DA=egress node (i.e., node-9). This means that all packet transiting through the source domain are in fact encapsulated/tunneled through it.

In this case, the shape of the new packet is:
	SA=1, DA=9
	SA=x, DA=y (i.e., the original SA/DA addresses)
	payload

Now, the packet travels from node-1 to node-9 and arrives in node-2. Assume that node-2 activated TI-LFA (IPFRR) where a backup path is pre-computed and installed into fib so that in case of interface 2to3 fails, the traffic follows the 50ms convergence rules or better(SRTE). Upon failure of interface 2to3, the packet is rerouted to node-4 with the following SRH inserted:

	SA=1, DA=5    (DA is now set as the first segment)
	SRH=(5, 9)
	SA=x, DA=y    (i.e., the original SA/DA addresses)
	payload
i.e., packet now has an SRH inserted by node-2 (transit node).
Ref.: few paper about TI-LFA:
http://www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2015/11524-fast-reroute-with-segment-routing-extending-fast-reroute.pdf
http://www.segment-routing.net/tutorials/2016-09-27-topology-independent-lfa-ti-lfa/

When the packet reaches node-9, it is decapsulated which means both outer header and SRH are removed.

    

still, in a source domain where you encap packets (and decap at egress) you can safely do pretty much what you want.
    
    routing header get back to a node that understands what they mean. 

ACK; The above should say SA (source address) where it says DA. 
it will since packet is sourced by node-1 so node-1 is the node receiving icmp messages.

If

this is out of scope of both draft-ietf-6man-segment-routing-header and draft-voyer-6man-extension-header-insertion.

If you need to add SRH’s you can always add an additional encap.

    

Sure thing, we’ll keep adding to the draft. Meanwhile I hope the explanations helped this thread progressing in a constructive way.
   
    Thanks & regards,
    
    Mike Heard
   
dan

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 24 May 2017 09:46:00 -0700

On Fri, May 5, 2017 at 2:14 PM, Voyer, Daniel <[email-masked]> wrote:
> Note that draft-voyer-6man-extension-header-insertion has been written
> with the purpose to illustrate _one_ evident use-case where header
> insertion is useful, not harmful and very beneficial. The intent of
> the draft is not to come with a complete set of solutions on how you
> can insert and update a source route path for a given packet.
>
> The first step towards header insertion, is to clearly document the
> practical, operational use-case where it is required (used) and safe.
[ ... ]
> As illustrated in the draft, the statement "Node 1 originates a packet
> P1 destined to 9 (SA=1, DA=9)” refers to the action the ingress node
> of the source domain consisting of encapsulating the incoming packet
> (i.e.: the packet entering in the source domain) into an outer header
> with SA=himself (i.e., node 1) and DA=egress node (i.e., node-9). This
> means that all packet transiting through the source domain are in fact
> encapsulated/tunneled through it.
>
> Now, the packet travels from node-1 to node-9 and arrives in node-2.
> Assume that node-2 activated TI-LFA (IPFRR) where a backup path is
> pre-computed and installed into fib so that in case of interface 2to3
> fails, the traffic follows the 50ms convergence rules or better(SRTE).
> Upon failure of interface 2to3, the packet is rerouted to node-4 with
> the following SRH inserted:
>
> outer header and SRH are removed.

Thank you for providing the explanation and the links to the white papers.
That very much helps to understand the use case that is presented, and in
particular how any ICMP error messages related to the SRH can be confined
to the SR domain. You may wish to consider including part or all of that
information in the next version of the draft. That being said, I still have
some comments and questions.

First, it still is not clear to me why it is considered decisively
advantageous to add the outer IPv6 header at the ingress to the SR domain
(node 1) and then insert the SRH at the intermediate that detects the link
failure (node 2) instead of just doing the encapsulation at the
intermediate node itself. An explanation would help. If it requires
consideration of other use cases to make that case, you may want to consider
adding one or more of those use cases to the draft.

Second, suppose that a second link failure is detected at node 4 (see
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-00#section-3
).
If that triggers SRH insertion because of fast reroute, then there will
be two SRH's in the packet, which would make it malformed. To avoid this
problem, it seems to me that node 4 would need to rebuild the existing SRH,
encapsulate the packet in another outer IPv6 header, or else drop the
packet.
By analogy with how fast protection switching works in transport NEs, I
understand that protecting agains multiple link failures may be out of
scope,
but even so, multiple link failures should not result in malformed packets.

Looking forward to further discussion.

Mike Heard