Yes its just recommended 😊
Juniper Internal -----Original Message----- From: Loa Andersson <[email protected]> Sent: Thursday, May 23, 2019 9:13 AM To: Rajesh M <[email protected]>; Robert Raszuk <[email protected]> Cc: [email protected]; SPRING WG <[email protected]>; [email protected]; [email protected]; Ron Bonica <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] 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: > 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 protected]> > *Sent:* Wednesday, May 22, 2019 7:55 PM > *To:* Rajesh M <[email protected]> > *Cc:* [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; SPRING WG > <[email protected]>; Peter Psenak <[email protected]>; Ron Bonica > <[email protected]> > *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 > <[email protected] > <mailto:[email protected]>> wrote: > > 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 protected] > <mailto:[email protected]>> > *Sent:* Wednesday, May 22, 2019 10:15 AM > *To:* Rajesh M <[email protected] <mailto:[email protected]>> > *Cc:* [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; SPRING WG <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]>; > Peter Psenak <[email protected] <mailto:[email protected]>> > *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, > <[email protected] > <mailto:[email protected]>> 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 > *Sent:* Wednesday, April 3, 2019 1:06 PM > *To:* [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > *Cc:* SPRING WG <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; Ron Bonica > <[email protected] <mailto:[email protected]>> > *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. > > 2. 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. > > 3. 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. > > 4. 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 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] <mailto:[email protected]> > Administrative Requests: > > 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_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=jrfq1dYsfk8_fBqqNNS-gdRsYxNXOt7r52G3GHN0iiQ&s=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OYo&e=> > > -------------------------------------------------------------------- > > _______________________________________________ > spring mailing list > [email protected] <mailto:[email protected]> > > 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=> > > > _______________________________________________ > spring mailing list > [email protected] > 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= > -- Loa Andersson email: [email protected] Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
