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

["Adrian Farrel" <[e-mail]>]

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 <[e-mail]> On Behalf Of Rajesh M
Sent: 23 May 2019 09:35
To: Loa Andersson <[e-mail]>; Robert Raszuk <[e-mail]>
Cc: SPRING WG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [spring] draft-ali-6man-spring-srv6-oam-00

Yes its just recommended 😊



Juniper Internal

-----Original Message-----
From: Loa Andersson <[e-mail]> 
Sent: Thursday, May 23, 2019 9:13 AM
To: Rajesh M <[e-mail]>; Robert Raszuk <[e-mail]>
Cc: [e-mail]; SPRING WG <[e-mail]>; [e-mail]; [e-mail]; Ron Bonica <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]>
> *Sent:* Wednesday, May 22, 2019 7:55 PM
> *To:* Rajesh M <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; SPRING WG 
> <[e-mail]>; Peter Psenak <[e-mail]>; Ron Bonica 
> <[e-mail]>
> *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=[e-mail]..org
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Wednesday, May 22, 2019 10:15 AM
>     *To:* Rajesh M <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; SPRING WG <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>;
>     Peter Psenak <[e-mail] <mailto:[e-mail]>>
>     *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=[e-mail]
>     <mailto:[e-mail]>> 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:* [e-mail] <mailto:[e-mail]>;
>         [e-mail] <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>
>         *Cc:* SPRING WG <[e-mail] <mailto:[e-mail]>>;
>         [e-mail] <mailto:[e-mail]>; Ron Bonica
>         <[e-mail] <mailto:[e-mail]>>
>         *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
>         [e-mail] <mailto:[e-mail]>
>         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
>     [e-mail] <mailto:[e-mail]>
>     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
> [e-mail]
> 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: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------