Subject: Re: [spring] About draft-ali-spring-srv6-oam-00

From: Loa Andersson <[email-masked]>
Date: Sat, 2 Jun 2018 10:21:13 +0200

Zafar,

My concern is that any load balancing tool might hash on the field where
you have the O-bit, if it does OAM traffic and normal payload traffic
will take different paths through the network.

How do you guarantee  this this will not happen?

/Loa

On 2018-05-29 19:11, Zafar Ali (zali) wrote:
> Hi Loa,
> 
> Thanks for your question.
> 
> O-bit "move" from SRH draft to this SRv6 OAM draft is part of a comment 
> received an agreement made during the LC of the SRH draft. Please review 
> the mail chain 
> https://www.ietf.org/mail-archive/web/ipv6/current/msg30131.html. There 
> was never a suggestion or agreement to "remove" O-bit or SRH.Flags field.
> 
> Load balancing and ECMP in an SRv6 network are explained in 
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-13#section-4.4. 
> An implementation is expected to use the minimum of (source, dest) 
> address and flow label in the outer IPv6 header to compute the hash. 
> RFC6437 describes the use of flow labels to compute a hash for IPv6 
> packets.
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *Loa Andersson <[email-masked]>
> *Date: *Tuesday, May 29, 2018 at 9:48 AM
> *To: *Huzhibo <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, 
> "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *Lizhenbin <[email-masked]>, Yangang <[email-masked]>
> *Subject: *Re: [spring] About draft-ali-spring-srv6-oam-00
> 
> Folks,
> 
> I thought we had an agreement to remove the O-bit. As ZhiBo Hu points
> 
> out other drafts drops it.
> 
> The obvious reason to not use an O-bit is that if it ever is part of
> 
> what an multipath functions hash on it will csue OAM traffic and
> 
> "normal" traffic to use different paths. This defeats the idea with
> 
> OAM traffic.
> 
> /Loa
> 
> On 2018-05-16 06:56, Huzhibo wrote:
> 
>     Hi,
> 
>     draft-ali-spring-srv6-oam-00 says The OAM packets are identified by
> 
>     setting the O-bit in SRH，But I Notice the latest
> 
>     I-D.6man-segment-routing-headerhas removed O-bit in the SRH extension
> 
>     header. I want to confirm that draft-ali-spring-srv6-oam-00 will also
> 
>     remove o-bit or keep the o-bit in the later version?
> 
>     Ths
> 
>     ZhiBo Hu
> 
>     _______________________________________________
> 
>     spring mailing list
> 
>     [email-masked]<mailto:[email-masked]>
> 
>     https://www.ietf.org/mailman/listinfo/spring
> 
> -- 
> 
> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
> 
> Senior MPLS Expert
> 
> Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
> 
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 2 Jun 2018 11:19:45 +0200

Hi Loa,

Is there any known implementations you can show here which builds its IPv6
load balancing hash bases on the *variable length* IPv6 extension headers
content ? Or is your concern simply a speculation ? :)

As Zafar already indicated bunch of IETF work went into proposing to use
flow label which is part of base IPv6 header (fixed 40 bytes) - to name a
few RFC6437, RFC6438, RFC6294 etc ... for that very purpose.

So at min if someone indeed wants to expose himself and construct a hash
based on the variable length fields a knob should be provided to allow to
configure such network element to skip extension headers.

Regards,
Robert.

On Sat, Jun 2, 2018 at 10:21 AM, Loa Andersson <[email-masked]> wrote:

>> the mail chain https://www.ietf.org/mail-arch
>> ive/web/ipv6/current/msg30131.html. There was never a suggestion or
>> agreement to "remove" O-bit or SRH.Flags field.
>>
>> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-
>> header-13#section-4.4. An implementation is expected to use the minimum
>> of (source, dest) address and flow label in the outer IPv6 header to
>> compute the hash. RFC6437 describes the use of flow labels to compute a
>> hash for IPv6 packets.
>>
>> Thanks
>>
>> Regards … Zafar
>>
>> "[email-masked]" <[email-masked]>,
>> "[email-masked]" <[email-masked]>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sun, 3 Jun 2018 17:12:50 +0000

+1 on what Robert mentioned; thanks Robert.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Saturday, June 2, 2018 at 5:20 AM
To: Loa Andersson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] About draft-ali-spring-srv6-oam-00

Hi Loa,

Is there any known implementations you can show here which builds its IPv6 load balancing hash bases on the variable length IPv6 extension headers content ? Or is your concern simply a speculation ? :)

As Zafar already indicated bunch of IETF work went into proposing to use flow label which is part of base IPv6 header (fixed 40 bytes) - to name a few RFC6437, RFC6438, RFC6294 etc ... for that very purpose.

So at min if someone indeed wants to expose himself and construct a hash based on the variable length fields a knob should be provided to allow to configure such network element to skip extension headers.

Regards,
Robert.

On Sat, Jun 2, 2018 at 10:21 AM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Zafar,

/Loa

O-bit "move" from SRH draft to this SRv6 OAM draft is part of a comment received an agreement made during the LC of the SRH draft. Please review the mail chain https://www.ietf..org/mail-archive/web/ipv6/current/msg30131.html<https://www.ietf.org/mail-archive/web/ipv6/current/msg30131.html>. There was never a suggestion or agreement to "remove" O-bit or SRH.Flags field.

Load balancing and ECMP in an SRv6 network are explained in https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-13#section-4.4<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-13#section-4..4>. An implementation is expected to use the minimum of (source, dest) address and flow label in the outer IPv6 header to compute the hash. RFC6437 describes the use of flow labels to compute a hash for IPv6 packets.

Thanks

Regards … Zafar

*From: *Loa Andersson <[email-masked]<mailto:[email-masked]>>
*Date: *Tuesday, May 29, 2018 at 9:48 AM
*To: *Huzhibo <[email-masked]<mailto:[email-masked]>>, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
*Cc: *Lizhenbin <[email-masked]<mailto:[email-masked]>>, Yangang <[email-masked]<mailto:[email-masked]>>
*Subject: *Re: [spring] About draft-ali-spring-srv6-oam-00

Folks,

OAM traffic.

/Loa

    Hi,

    Ths

    ZhiBo Hu

    spring mailing list

    [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

--

Loa Andersson                        email: loa@pi..nu<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

Senior MPLS Expert

--