Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain

> On Apr 4, 2017, at 10:38 AM, Satoru Matsushima <satoru.matsushima@gmail.com> wrote:
> 
> Hello Mark,
> 
> Thank you, it looks very interesting discussion. I’d clarify a bit to your following point:
> 
>> [...]
> 
>> Node 5 receives the packet, and as it is DA=5, decapsulates the inner
>> SA=1, DA=9 packet. Node 5 then submits that packet to the standard
>> IPv6 forwarding table, resulting in it being forwarded to Node 3,
>> which then forwards it to Node 9. All of this is happening using
>> conventional IPv6 destination based forwarding.
> 
> This behavior of node 5 assumes that there’s on-demand virtual tunnel between node 2 and node 5 prior to the failure. Is that correct?

this is part of TI-LFA (and more general fast re-rpoute) technology.

yes, the repair path is pre-computed in the form of a segment list.

>> Encapsulation is solving this problem by effectively creating a
>> on-demand virtual link or tunnel between Node 2 and Node 5, getting
>> the original packet past the failure point to a point along the
>> original packet's forwarding path. Once there, it pops out of the
>> virtual link and is sent along its way. I don't think the insertion of
>> the EH and DA swapping method could be described the same way or could
>> be described as simply.
> 
> So that looks node 9 should define DA=9 semantics which the node pops an outer header and then forward the payload to the inner IPv6 destination based on the routing table. Basically an IP address of a node represents the node itself and receiving packets will be punt to the control-plane. So it seems that the node behavior doesn't work for conventional nodes.

correct. Please read draft-filsfils-spring-srv6-network-programming and you’ll see we defined an explicit behavior for that.

Suc behavior is signaled in the control plane of the infrastructure (isis, ospf). See extensions described in draft-bashandy-isis-srv6-extensions.

> To that behavior works, I think that it requires additional spec to define such semantics and some control-plane to signal that semantics to other node.

correct. See above.

> If I comment to that it would be a certain volume of load for signaling and maintaining the states to the control-planes, even the data-plane behavior can be kept in conventional. And it would also require tunnel configurations to the all nodes in each node which I don’t want to do in our operations.

good point, but I’m afraid you’re not familiar with TI-LFA. There’s very little state to keep and there’s no tunnel provisioning. This is traditional LFA/IPFRR.

> I have to admit my ignorant, but I’m really appreciate if you let me know about that kind of on-demand tunneling technologies without bunch of signaling to maintain states and configuration burdens.

draft-filsfils-spring-srv6-network-programming 
draft-bashandy-isis-srv6-extensions
RFC7855
draft-ietf-spring-resiliency-use-case
draft-francois-rtgwg-segment-routing-ti-lfa

Keep in mind that LFA technologies have been deployed for a few years already and TI-LFA is being deployed as we speak.

s.

> 
> Best regards,
> --satoru
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------