Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

[Mark Smith <[e-mail]>]

Hi Gunter,

On 8 November 2017 at 16:05, Van De Velde, Gunter (Nokia - BE/Antwerp)
<[e-mail]> wrote:
> There few other drawbacks that we considered when we selected to use Flow-label instead of an EH solution for SRv6 alternate marking:
>
> * easier backward compatibility because nothing breaks if a transit router does not have the capability of understanding the Flow label context... in that case the flow-label in the outer tunnel header is just a flow-label
> * Having a HbH EH seems less backward compatible, and will be less easy to use unless ALL routers in the domain support these type of headers in the fast-path... it just seems complex because of all the if-then-but involved to implement, use and operate...

I think that is an advantage of using destination addresses to encode
this processing.

In addition to identifying a host, I think in IP a destination address
is also and more fundamentally identifying an exit point from the
forwarding domain. It indicates where processing for forwarding to the
DA stops, and where other more complex processing of the packet is to
occur, using information past the fixed IP header, and likely in the
payload. Processing of the IPv6 Routing Header EH, or information in
the payload e.g. transport and further upper layer processing are
examples.

Using the DA to encode this more complex processing means that it is
easy to retrofit into existing devices and models. There is no need to
replace existing IPv6 forwarding devices, because they already support
DA based forwarding. An SR box with the DA could be hung off the side
of an existing router, do its magic, and then resubmit the newly SR
processed packet back into the conventional forwarding domain, to be
forwarded onto the next SR box that owns the specified DA (Inspired by
how Ipsilon Networks added IP forwarding to ATM networks).


> * For HW based routers (i.e. in Nokia case having user-plane switching capability scale of 2.8T per NPU) the support nearly comes for free as support is already there... nothing extra is needed from a nodal perspective
> * Less bits on the wire... going SRv6 has already a significant bits-on-wire tax because of the outer IPv6 header and the SRv6 EH and all the source routing headers
>

"Scrounging" bits from other fields because the SRv6 header has become
large seems to be trying to avoid fixing the problem where it is
caused.

I'd guess a lot of this size has come from the use of 128 bit IPv6
addresses to identify segments. I think a question is do they really
need to be that large?

I thought about per-packet overhead in the context of IPv6 tunnelling
a few years ago. It occurred to me that if tunnel end-points were
identified using /64s rather than /128s, then the IID parts of the
outer IPv6 source and destination addresses could be used for
something else. If those other things came from the inner packet, then
they could be removed from the inner packet, reducing the effective
tunnelling overhead.

I wrote up some of those ideas in "Enhancing Virtual Network
Encapsulation with IPv6"
(https://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-07).
More recently I took the next step and developed a tunnelling method,
although the savings weren't quite as high as I'd hoped due to the 8
octet minimum size requirement of an Extension Header - "Skinny IPv6
in IPv6 Tunnelling"
(https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00)

IPv6 networks have a lot of /64s. In this draft's scenario, ULA
addressing should be being used for the outer header addressing to
minimise leaking. ULA /48s have 65K /64s, and if that isn't enough,
multiple ULA /48 prefixes can be used to generate more /64s.

It would be a significant change to SR at this time I'd suspect,
however I think using /64s as Segment IDs rather than /128s would make
a significant SRH size overhead saving, avoiding the need to try to
leverage other non-SR fields, such as the Flow Label,  for SR or
related information.

Regards,
Mark.


> So, indeed a new type of EH may be a solution space proposal, however, I do not think it is as pragmatic as using the flow-label in the outer IPv6 SRv6 header because of all the benefits flow-label usage gives. The Flow-label proposal, is basically something that routers can do right now,  and it does not break any IPv6 rules and is expected to be supported in line-rate by the fast path switching of routers by default.
>
> Indeed she solution proposed in the draft, is for the moment assumed to be exclusive from other usages (with exception of entropy) of the flow-label in the controlled operator domain... it does not necessary have to be exclusive, but it seems the most pragmatic. Currently, operator traditionally do not use flow-label at all, hence the above assumption seems reasonable.
>
> G/
>
>
> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Tuesday, November 7, 2017 23:28
> To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt
>
> On Tue, Nov 7, 2017 at 11:53 AM, Van De Velde, Gunter (Nokia -
> BE/Antwerp) <[e-mail]> wrote:
>> Hi Tom,
>>
>> The closed system here is defined by the SRv6 tunnels… The flow-label is set “only” by the tunnel head-end router “on the outer IPv6 header”. The tunnel head-end router can do this because it is the device that created the outer IP header.
>> The original IPv6 packet is riding inside the tunnel, and as result
>> the original flow label and original IPv6 header is left untouched. The closed system is the network between the tunnel head-end (=where the outer IPv6 header is added) and the tunnel tail-end (=where the outer header is removed). This type of closed system is easy to deploy… take for example a MPLS/VPN backbone…. Or a VxLAN network… The SRv6 network is something of similar simplicity.
>>
>> The IPv6 device that generates an IPv6 packet can set the flow label, and that is what devices have been doing all the time. This draft proposes nothing new from that perspective.
>>
>> Why do you say ‘repurposing’ the bits? Nothing is repurposed. This proposal is respecting RFC6437. In our informational proposal the flow-label just remains flow-label. Routers can be made to match upon flow-label values easily. I know my Nokia products can do that very easily, because the flow-label is always found at the same place in the IPv6 header. However, checking on EHs is a few dimensions more complicated. When I must make my router match for content in EHs, then first it must check if the relevant EH is inserted, then the corresponding EH must be identified and then the content has to be checked… This EH checking is non-trivial as result… For a HW based router (my Nokia router for example) the checking of flow-label is as simple as checking for a DSCP value because the operation involved is exactly the same.
>
> I don't believe the EH processing needs to be complicated. In this case the assumption is that network operator is inserting the headers so the HBH EH with a latency measurement option could be implemented to always be in the same position, have the same length, and only set with one option for latency. The router processingcan be optimized to handle this case. Existence and verification of the EH can all be done with simple checks and TCAM could be used to match the common header pattern. The IP header and extension header should fit well within the parsing buffer of typical routers.
>
>>
>> Tom, if your additional suggestions for using flow labels is respecting RFC6437 then what stops you from documenting those thoughts? The alternate marking principle documented in this draft for SRv6 is something that is driven by operator themselves, and is based upon real operator requirement. Feel free to further discuss with the Telekom Italia co-authors (Guiseppe and Mauro) on TI needs for such passive measurement mechanism (loss, latency, jitter, etc).
>
> The fact that operators want passive latency measurements is not the same as saying that applying a format to the flow label is a requirement. It is the mechanism of this proposal this is in question.
>
> Tom
>
>
>>
>> G/
>>
>>
>>
>> On 07/11/2017, 19:14, "Tom Herbert" <[e-mail]> wrote:
>>
>>     On Tue, Nov 7, 2017 at 9:13 AM, Van De Velde, Gunter (Nokia -
>>     BE/Antwerp) <[e-mail]> wrote:
>>     > To me it seems that looking at FL is much easier for a HW based
>> router then looking at EHs in a hop-by-hop fashion…
>>
>>     Easier for whom? Repurposing bits in the IP header even for a narrow
>>     use case in a closed system doesn't seem particularly easy to
>>     standardize or deploy. As Mark pointed out there's a lot of complexity
>>     around ensuring that the system really is closed and all required
>>     behavior is maintained.
>>
>>     Another obvious question with this approach is does it mean that flow
>>     label bits are now fair game to be defined for even more purposes?
>>     Latency measurement isn't be the only potential use case. For
>>     instance, I know there's a lot of people that want hosts to mark
>>     packets with a "retransmitted" bit so that routers can keep stats for
>>     tracked flows. IMO, if using flow bits like this is the right answer
>>     then there should be a generic protocol specification that defines the
>>     operation and how bits are allocated for all the potential uses.
>>
>>     Tom
>>
>>     >
>>     > G/
>>     >
>>     > On 07/11/2017, 17:58, "Tom Herbert" <[e-mail]> wrote:
>>     >
>>     >     On Tue, Nov 7, 2017 at 7:26 AM, Van De Velde, Gunter (Nokia -
>>     >     BE/Antwerp) <[e-mail]> wrote:
>>     >     > A transit router does not look at EHs if it is not configured for the IPv6 Destination address.. so its not usable in that case.
>>     >     >
>>     >     They do look at hop-by-hop options. Previously it was required that
>>     >     all nodes in the path must process them, but that was relaxed a bit in
>>     >     RFC8200. If they are only used for tunneling across a controlled
>>     >     domain then the typical concern that intermediate nodes don't properly
>>     >     handle hop-by-hop options can be addressed.
>>     >
>>     >     Tom
>>     >
>>     >     > G/
>>     >     >
>>     >     > -----Original Message-----
>>     >     > From: Tom Herbert [mailto:[e-mail]]
>>     >     > Sent: Tuesday, November 7, 2017 16:16
>>     >     > To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[e-mail]>
>>     >     > Cc: [e-mail]
>>     >     > Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt
>>     >     >
>>     >     > On Mon, Nov 6, 2017 at 10:44 PM, Van De Velde, Gunter (Nokia -
>>     >     > BE/Antwerp) <[e-mail]> wrote:
>>     >     >> Hi Tom,
>>     >     >>
>>     >     >> -->
>>     >     >> From section 1:
>>     >     >>
>>     >     >> "Based on these considerations, it is allowed to use the flow label field in a managed domain, assuming when a packet leaves the domain, the original flow label value MUST be restored."
>>     >     >>
>>     >     >> In this proposal, if two bits are overwritten by an intermediate node, how are their original values restored when leaving the domain?
>>     >     >> -->
>>     >     >>
>>     >     >> GV>  Because the field that are being fiddled with are on the IPv6 SRv6 outer encapsulation header. When the original packet leaves the controlled domain, then that header is removed again, and the original IPv6 packet with original headers appear again.
>>     >     >>
>>     >     > Gunter,
>>     >     >
>>     >     > If the measurements are always coincident with the use of SRv6 then why not put the measurement information in the SR EH or some other EH (hop-by-hop or est opt maybe) used only in the controlled domain? This also could be more flexible since the algorithm wouldn't be constrained to just two bits of data.
>>     >     >
>>     >     > Tom
>>     >
>>     >
>>
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops