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

From: Rajesh M <[email-masked]>
Date: Wed, 22 May 2019 01:08:04 +0000

Guys in this draft I see that all the example such as ping, traceroute to ipv6 address-> use SRH insertion rather than SRH encapsulation.
This is intentionally done to reduce the packet size   (since underlying data can be only ipv6) ?

Juniper Internal
From: Rajesh M
Sent: Wednesday, April 3, 2019 1:06 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: SPRING WG <[email-masked]>; [email-masked]; Ron Bonica <[email-masked]>
Subject: draft-ali-6man-spring-srv6-oam-00

Please find few comments on this draft

  1.  Section 3.1.1 , below must be Ref2

Ref1: Hardware (microcode) just punts the packet. Software (slow path)
implements the required OAM
mechanism. Timestamp is not carried in the packet forwarded to the
next hop.

  1.  4.1.2.2, here it must be N2 (page 10)

If the target SID is not locally programmed, N4 responses with
the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not
locally implemented (TBA)"); otherwise a success is returned.

  1.  4.1.2.2, here it must be B:4:C52 (page 11)
The ICMPv6 process at node N4
checks if its local SID (B:2:C31) is locally programmed or not
and responds to the ICMPv6 Echo Request.

  1.  4.3.2.2, here it must be B:4:C52 (page 16)
The traceroute process at
node N4 checks if its local SID (B:2:C31) is locally
programmed.

5)  in below two cases is it B5:: or it must be A:5:: ?
> ping A:5:: via segment-list B:2:C31, B:4:C52
Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds:
!!!!!

> traceroute A:5:: via segment-list B:2:C31, B:4:C52
Tracing the route to B5::

Thanks
Rajesh

Juniper Internal

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 May 2019 14:44:47 +1000

EH insertion is not compliant with RFC8200. Equipment doing so cannot claim
compliance with RFC8200.

On Wed., 22 May 2019, 11:08 Rajesh M, <mrajesh=[email-masked]>
wrote:

> Guys in this draft I see that all the example such as ping, traceroute to
> ipv6 address-> use SRH insertion rather than SRH encapsulation.
>
> *From:* Rajesh M
> *Sent:* Wednesday, April 3, 2019 1:06 PM
> *To:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Cc:* SPRING WG <[email-masked]>; [email-masked]; Ron Bonica <
> [email-masked]>
> *Subject:* draft-ali-6man-spring-srv6-oam-00
>
>
>
> *Ref1*: Hardware (microcode) just punts the packet. Software (slow path)
>
> If the target SID is not locally programmed, *N4* responses with
>
> checks if its local SID (*B:2:C31*) is locally programmed or not
>
> node N4 checks if its local SID (*B:2:C31*) is locally
>
> programmed.
>
>
>
> Sending 5, 100-byte ICMP Echos to *B5::,* timeout is 2 seconds:
>
> !!!!!
>
>
>
> Tracing the route to *B5::*
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
> Juniper Internal
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Rajesh M <[email-masked]>
Date: Wed, 22 May 2019 13:56:08 +0000

Agreed (cannot claim compliance with RFC8200). Authors please comment

Guys in this draft I see that all the example such as ping, traceroute to ipv6 address-> use SRH insertion rather than SRH encapsulation.This is intentionally done to reduce the packet size   (since underlying data can be only ipv6) ?

From: Mark Smith <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 22, 2019 10:15 AM
To: Rajesh M <[email-masked]<mailto:[email-masked]>>
Cc: [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]>; [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Peter Psenak <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ali-6man-spring-srv6-oam-00

EH insertion is not compliant with RFC8200. Equipment doing so cannot claim compliance with RFC8200.

On Wed., 22 May 2019, 11:08 Rajesh M, <mrajesh=[email-masked]<mailto:[email-masked]>> wrote:
Guys in this draft I see that all the example such as ping, traceroute to ipv6 address-> use SRH insertion rather than SRH encapsulation.
This is intentionally done to reduce the packet size   (since underlying data can be only ipv6) ?

Juniper Internal

Juniper Internal
From: Rajesh M
Sent: Wednesday, April 3, 2019 1:06 PM
To: [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]>; [email-masked]<mailto:[email-masked]>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Ron Bonica <[email-masked]<mailto:[email-masked]>>
Subject: draft-ali-6man-spring-srv6-oam-00

Thanks
Rajesh

Juniper Internal
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=jrfq1dYsfk8_fBqqNNS-gdRsYxNXOt7r52G3GHN0iiQ&s=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OYo&e=>
--------------------------------------------------------------------

---

From: Rajesh M <[email-masked]>
Date: Wed, 22 May 2019 14:44:58 +0000

I think as long as we ensure below order it must be OK.

When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order:

      IPv6 header
      Hop-by-Hop Options header
      Destination Options header (note 1)
      Routing header
      Fragment header
      Authentication header (note 2)
      Encapsulating Security Payload header (note 2)
      Destination Options header (note 3)
      Upper-Layer header

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, May 22, 2019 7:55 PM
To: Rajesh M <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; SPRING WG <[email-masked]>; Peter Psenak <[email-masked]>; Ron Bonica <[email-masked]>
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00

Hi Rajesh,

I think some folks are just confusing "insertion of new EH" from "modification of existing EH" ? To me those are completely different actions.

And processing of any EH is explicitly allowed by RFC8200 as long as dst address in the top v6 header is the processing entity which seems to be the case here. Such processing nowhere in RFC8200 seems to be prohibited.

Let's also observe that as it is often the case with OEM it is actual network elements who act as both src and dst of the end to end OEM sessions :).

Thx,
R.

On Wed, May 22, 2019 at 3:56 PM Rajesh M <mrajesh=[email-masked]<mailto:[email-masked]>> wrote:
Agreed (cannot claim compliance with RFC8200). Authors please comment

On Wed., 22 May 2019, 11:08 Rajesh M, <mrajesh=[email-masked]<mailto:[email-masked]>> wrote:
Guys in this draft I see that all the example such as ping, traceroute to ipv6 address-> use SRH insertion rather than SRH encapsulation.
This is intentionally done to reduce the packet size   (since underlying data can be only ipv6) ?

Juniper Internal

Juniper Internal

Juniper Internal
From: Rajesh M

Thanks
Rajesh

Juniper Internal
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=jrfq1dYsfk8_fBqqNNS-gdRsYxNXOt7r52G3GHN0iiQ&s=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OYo&e=>
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=bA6bNX7XD3BHTzukhcoIS-aqZi6dWcnVVdTfYB1goG8&s=fia6hQTqXh09fn6GLOkZIbXdPoNqldBthMQdxAuNWxM&e=>

---

From: Rajesh M <[email-masked]>
Date: Wed, 22 May 2019 13:51:19 +0000

From: Mark Smith <[email-masked]>
Sent: Wednesday, May 22, 2019 10:15 AM
To: Rajesh M <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; SPRING WG <[email-masked]>; [email-masked]; Peter Psenak <[email-masked]>
Subject: Re: draft-ali-6man-spring-srv6-oam-00

Juniper Internal

Juniper Internal
From: Rajesh M

Thanks
Rajesh

Juniper Internal

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 May 2019 16:24:37 +0200

Hi Rajesh,

I think some folks are just confusing "insertion of new EH" from
"modification of existing EH" ? To me those are completely different
actions.

And processing of any EH is explicitly allowed by RFC8200 as long as dst
address in the top v6 header is the processing entity which seems to be the
case here. Such processing nowhere in RFC8200 seems to be prohibited.

Let's also observe that as it is often the case with OEM it is actual
network elements who act as both src and dst of the end to end OEM sessions
:).

Thx,
R.

On Wed, May 22, 2019 at 3:56 PM Rajesh M <mrajesh=
[email-masked]> wrote:

> ipv6 address-> use SRH insertion rather than SRH encapsulation.This is
> intentionally done to reduce the packet size   (since underlying data can
> be only ipv6) ?
>
>
>
>
>
> *From:* Mark Smith <[email-masked]>
> *Sent:* Wednesday, May 22, 2019 10:15 AM
> *To:* Rajesh M <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; SPRING WG <
> [email-masked]>; [email-masked]; Peter Psenak <[email-masked]>
> *Subject:* Re: draft-ali-6man-spring-srv6-oam-00
>
>
>
> On Wed., 22 May 2019, 11:08 Rajesh M, <mrajesh=
> [email-masked]> wrote:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=jrfq1dYsfk8_fBqqNNS-gdRsYxNXOt7r52G3GHN0iiQ&s=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OYo&e=>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Rajesh M <[email-masked]>
Date: Wed, 22 May 2019 14:43:33 +0000

IPv6 header

Hi Rajesh,

Thx,
R.

Juniper Internal

Juniper Internal

Juniper Internal
From: Rajesh M

Thanks
Rajesh

Juniper Internal

---

From: Loa Andersson <[email-masked]>
Date: Thu, 23 May 2019 11:42:48 +0800

Rajesh,

It seems to me that "it is recommended" indicate that the ordering is
optional/OPTIONAL. Does this document (or your comment) create a
MANDATORY ordering of EH's??

/Loa

On 2019-05-22 22:44, Rajesh M wrote:
> When more than one extension header is used in the same packet, it is 
> recommended that those headers appear in the following order:
> 
>        IPv6 header
> 
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, May 22, 2019 7:55 PM
> [email-masked]; [email-masked]; [email-masked]; SPRING WG 
> <[email-masked]>; Peter Psenak <[email-masked]>; Ron Bonica 
> <[email-masked]>
> *Subject:* Re: [spring] draft-ali-6man-spring-srv6-oam-00
> 
> Hi Rajesh,
> 
> address in the top v6 header is the processing entity which seems to be 
> the case here. Such processing nowhere in RFC8200 seems to be prohibited.
> 
> network elements who act as both src and dst of the end to end OEM 
> sessions :).
> 
> Thx,
> 
> R.
> 
> On Wed, May 22, 2019 at 3:56 PM Rajesh M 
> <mrajesh=[email-masked]..org 
> <mailto:[email-masked]>> wrote:
> 
>     Guys in this draft I see that all the example such as ping,
>     traceroute to ipv6 address-> use SRH insertion rather than SRH
>     encapsulation.This is intentionally done to reduce the packet size
>        (since underlying data can be only ipv6) ?
> 
>     *From:* Mark Smith <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Rajesh M <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [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]>; [email-masked]
>     <mailto:[email-masked]>; SPRING WG <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>;
>     Peter Psenak <[email-masked] <mailto:[email-masked]>>
>     On Wed., 22 May 2019, 11:08 Rajesh M,
>     <mrajesh=[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Guys in this draft I see that all the example such as ping,
>         traceroute to ipv6 address-> use SRH insertion rather than SRH
>         encapsulation.
> 
>         *To:* [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]>; [email-masked]
>         <mailto:[email-masked]>
>         *Cc:* SPRING WG <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>; Ron Bonica
>         <[email-masked] <mailto:[email-masked]>>
>          2. 4.1.2.2, here it must be N2 (page 10)
> 
>          3. 4.1.2.2, here it must be B:4:C52 (page 11)
> 
>          4. 4.3.2.2, here it must be B:4:C52 (page 16)
> 
>         [email-masked] <mailto:[email-masked]>
>         Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=bA6bNX7XD3BHTzukhcoIS-aqZi6dWcnVVdTfYB1goG8&s=fia6hQTqXh09fn6GLOkZIbXdPoNqldBthMQdxAuNWxM&e=>
> 
> 

-- 

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 May 2019 10:31:44 +0200

Hi Loa,

On Thu, May 23, 2019 at 5:42 AM Loa Andersson <[email-masked]> wrote:

> optional/OPTIONAL.

Indeed. There is no MUST there. That is precisely what section 4.1 of
RFC8200 says:

4.1 <https://tools.ietf.org/html/rfc8200#section-4.1>.  Extension Header Order

*  recommended *that those headers appear in the following order:

Does this document (or your comment) create a
> MANDATORY ordering of EH's??

If by "this document" you mean draft-ali-6man-spring-srv6-oam then no - I
do not see any text there which would even attempt to enforce any EH
ordering.

As far as creating MANDATORY ordering "by a comment" that must be pretty
new extension to the IETF process :)

Best,
R.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 23 May 2019 09:48:17 +0100

Hi all,

I don't think that a loose statement of recommendation is quite enough.

Trivially, the IPv6 header must come first and the upper layer header must come last.

I think that although the inclusion of the two destination options headers is optional, their positions are quite tightly constrained.

Personally, I think this is a good candidate for mandating ordering and probably using RBNF (RFC 5030) to describe the possibilities.

Thanks,
Adrian

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Rajesh M
Sent: 23 May 2019 09:35
To: Loa Andersson <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] draft-ali-6man-spring-srv6-oam-00

Yes its just recommended 😊

Juniper Internal

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Thursday, May 23, 2019 9:13 AM
To: Rajesh M <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>; [email-masked]; [email-masked]; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00

Rajesh,

It seems to me that "it is recommended" indicate that the ordering is optional/OPTIONAL. Does this document (or your comment) create a MANDATORY ordering of EH's??

/Loa

On 2019-05-22 22:44, Rajesh M wrote:
> And processing of any EH is explicitly allowed by RFC8200 as long as 
> dst address in the top v6 header is the processing entity which seems 
> to be the case here. Such processing nowhere in RFC8200 seems to be prohibited.
> 
>         https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B6IE46DSDAOG-FbuEW2lRdgM_6U&s=2ix9kKHToQUM7NsHhHBM_SSVgBdT3cz6d2L0OrXshSo&e=
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B6IE46DSDAOG-FbuEW2lRdgM_6U&s=QWz-MtJwmiTTnDkJ2vbryepA7yAALs_X2LVHmyihE7A&e=
>     
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
> lman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXc
> WzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=bA6bNX7XD3BHTzuk
> hcoIS-aqZi6dWcnVVdTfYB1goG8&s=fia6hQTqXh09fn6GLOkZIbXdPoNqldBthMQdxAuN
> WxM&e=>
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_spring&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
> zoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B
> 6IE46DSDAOG-FbuEW2lRdgM_6U&s=QWz-MtJwmiTTnDkJ2vbryepA7yAALs_X2LVHmyihE
> 7A&e=
> 

--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 23 May 2019 16:48:54 +0800

Robert,

I think that I might have been unclear,

- I understand that RFC 8200 does not use normative language, nor MUST
   neither RECOMMENDED, just normal English "recommended". I also
   understand that this is fine for the situation before draft-ali-6man-
   spring-srv6-oam, we recommend an order for the extension headers, but
   nothing bad happens if that order is not strictly followed.

- What Rajesh comment seems to imply is that it will fore draft-
   ali-6man-spring-srv6-oam as long recommended the ordering is kept.

- what I was wondering was if it is possible to demonstrate that it
   will not work if the recommended ordering is not kept.

- and a follow up to this, if it is possible to demonstrate that it will
   not work if the recommended is not kept, should we in this case mnake
   the now "recommended" order "MANDATORY"?

/Loa

On 2019-05-23 16:31, Robert Raszuk wrote:
> Hi Loa,
> 
> On Thu, May 23, 2019 at 5:42 AM Loa Andersson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Rajesh,
> 
> If by "this document" you mean draft-ali-6man-spring-srv6-oam then no - 
> I do not see any text there which would even attempt to enforce any EH 
> ordering.
> 
> R..

--

---

From: Rajesh M <[email-masked]>
Date: Thu, 23 May 2019 08:34:51 +0000

Juniper Internal

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Thursday, May 23, 2019 9:13 AM
To: Rajesh M <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>; [email-masked]; [email-masked]; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00

Rajesh,

/Loa

--

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 May 2019 12:17:07 +0200

All,

May I ask where this concern is coming from ?

All hardware I am aware of can easily do simple match on the type field
rather then make any assumptions on the order of EHs.

So putting aside main topic of this thread (as honestly I see no relation)
it would be pretty bad to mandate any order, then have some hardware making
any assumptions on it.

After all the entire concept of EH is to have v6 packet format extendable
in the future - am I wrong ?

Best,
R.

On Thu, May 23, 2019, 10:48 Adrian Farrel <[email-masked]> wrote:

> I think that although the inclusion of the two destination options headers
> is optional, their positions are quite tightly constrained.
>
> Personally, I think this is a good candidate for mandating ordering and
> probably using RBNF (RFC 5030) to describe the possibilities.
>
> Thanks,
> Adrian
>
> Cc: [email-masked]; SPRING WG <[email-masked]>; [email-masked];
> [email-masked]; Ron Bonica <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> optional/OPTIONAL. Does this document (or your comment) create a MANDATORY
> ordering of EH's??
>
> /Loa
>
> >         <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=jrfq1dYsfk8_fBqqNNS-gdRsYxNXOt7r52G3GHN0iiQ&s=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OYo&e=
> >
> >

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 May 2019 20:33:24 +1000

On Thu, 23 May 2019 at 20:17, Robert Raszuk <[email-masked]> wrote:
> All hardware I am aware of can easily do simple match on the type field rather then make any assumptions on the order of EHs.
>
> So putting aside main topic of this thread (as honestly I see no relation) it would be pretty bad to mandate any order, then have some hardware making any assumptions on it.
>
> After all the entire concept of EH is to have v6 packet format extendable in the future - am I wrong ?

There's other advice in RFC8200, later on from the text that Rajesh quoted.

"If and when other extension headers are defined, their ordering
constraints relative to the above listed headers must be specified."

Better yet, there is a whole section of RFC8200 on this topic:

4.1.  Extension Header Order

https://tools.ietf.org/html/rfc8200#section-4.1

>> Yes its just recommended
>> >     <mailto:40juniper.net@dmarc..ietf.org>> wrote:
>> >
>> Administrative Requests: https://www..ietf.org/mailman/listinfo/ipv6

---

From: Ron Bonica <[email-masked]>
Date: Thu, 23 May 2019 14:30:27 +0000

Adrian,

RFC 8200 recommends extension header order for some very good reasons. And those reasons are so good, that they go beyond recommendations. For example,

- If the Hop-by-hop extension header does not immediately follow the base IPv6 header, it is likely to be ignored by downstream routers.
- The first Destination Options header (i.e., the one that precedes the Routing header) is intended to be processed by every node listed in the routing header. If that Destination Options header does not preceded the routing header, it will only be processed by the ultimate destination only.
- If the fragment header comes before the Routing header, the first segment endpoint will either drop or reassemble the packet. Both of these are undesirable.

                                                                                  Ron

Juniper Internal

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, May 23, 2019 4:48 AM
To: 'Rajesh M' <mrajesh=[email-masked]>; 'Loa Andersson' <[email-masked]>
Cc: 'SPRING WG' <[email-masked]>; [email-masked]
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00

Hi all,

Thanks,
Adrian

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Rajesh M
Sent: 23 May 2019 09:35
To: Loa Andersson <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] draft-ali-6man-spring-srv6-oam-00

Juniper Internal

-----Original Message-----
From: Loa Andersson <[email-masked]>
Sent: Thursday, May 23, 2019 9:13 AM
To: Rajesh M <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>; [email-masked]; [email-masked]; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00

Rajesh,

/Loa

On 2019-05-22 22:44, Rajesh M wrote:
> lman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWz
> oCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=jrfq1dYsfk8_fBqqNN
> S-gdRsYxNXOt7r52G3GHN0iiQ&s=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OY
> o&e=>
>         

-- 

Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=dCPZhZXrhcCILdx4IfTvnoiAs5FZdj1AVV07onkdkmE&s=2TENWO4SdrAao-4yRRUhdg71A9zy2tqIbd2-tFQvzcw&e=

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=dCPZhZXrhcCILdx4IfTvnoiAs5FZdj1AVV07onkdkmE&s=jdLVTMA0RxXuSrrAVbM3Ki35ywj1uAzgEVi-3FFGBGc&e=

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 23 May 2019 15:39:21 +0100

Of course, s/5030/5511/

Stop typing from memory and look it up!

Adrian

-----Original Message-----
From: Ron Bonica <[email-masked]> 
Sent: 23 May 2019 15:30
To: [email-masked]; 'Rajesh M' <mrajesh=[email-masked]>; 'Loa Andersson' <[email-masked]>
Cc: 'SPRING WG' <[email-masked]>; [email-masked]
Subject: RE: [spring] draft-ali-6man-spring-srv6-oam-00

Adrian,

                                                                                  Ron

Juniper Internal

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, May 23, 2019 4:48 AM
To: 'Rajesh M' <mrajesh=[email-masked]>; 'Loa Andersson' <[email-masked]>
Cc: 'SPRING WG' <[email-masked]>; [email-masked]
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00

Hi all,

Thanks,
Adrian

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Rajesh M
Sent: 23 May 2019 09:35
To: Loa Andersson <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] draft-ali-6man-spring-srv6-oam-00

Juniper Internal

-----Original Message-----
From: Loa Andersson <[email-masked]>
Sent: Thursday, May 23, 2019 9:13 AM
To: Rajesh M <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>; [email-masked]; [email-masked]; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00

Rajesh,

/Loa

--

---

From: Tom Herbert <[email-masked]>
Date: Thu, 23 May 2019 08:36:48 -0700

> in the future - am I wrong ?

Correct. EH is the extensibility mechanism of IPv6 and RFC8200 prescribes
the requirements. This includes the ordering requirements of EH and that is
deployed. Similarly RFC8200 has no allowance for extension header insertion
or deletion (the problems with those have previously been discussed on the
list). Segment routing is one instance of routing header and doesn't define
a new extension header, so I'm also missing what the concern is with regard
to the requirements of RFC8200.

Tom

>> I think that although the inclusion of the two destination options
>> headers is optional, their positions are quite tightly constrained.
>>
>> >     <mailto:40juniper.net@dmarc..ietf.org
>> <[email-masked]>>> wrote:
>> >
>> >         <[email-masked] <rbonica@juniper..net> <mailto:
>> [email-masked]>>
>> <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 23 May 2019 22:48:34 +0000

Rajesh,

Re: you comment: “I see that all the example such as ping, traceroute to ipv6 address-> use SRH insertion rather than SRH encapsulation.”

This comment is not correct. None of the ping, traceroute examples in the draft uses SRH insertion.

Thanks

Regards … Zafar

From: Rajesh M <[email-masked]>
Date: Tuesday, May 21, 2019 at 9:08 PM
To: "Clarence Filsfils (cfilsfil)" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, "Nagendra Kumar Nainar (naikumar)" <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, "Rakesh Gandhi (rgandhi)" <[email-masked]>, "Frank Brockners (fbrockne)" <[email-masked]>
Cc: SPRING WG <[email-masked]>, "[email-masked]" <[email-masked]>, Ron Bonica <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>
Subject: RE: draft-ali-6man-spring-srv6-oam-00

Juniper Internal
From: Rajesh M

Thanks
Rajesh

Juniper Internal