Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

[Joel Halpern Direct <[e-mail]>]

Zafar, thank you for taking steps to address my concerns.  There seem to 
be several issues remaining.  I am not sure I spotted them all, as the 
ones I see may be masking other issues.

[Side note to the chairs:  I have no idea how to enter a general 
discussion of this sort as a pull request.  I do not understand the 
desired behavior well enough to propose specific text.]

First, the draft still has as its focus "punt to the control processor". 
  But "Punt to the control process" is not an external observable.  It 
is not a subject for standardization.  What needs to be standardized is 
the behavior to be applied to the packet, not who applies it.  Heck, if 
someone implements all this logic in their fast path (or if they have 
only one path and therefore can not punt anywhere) it should still be 
possible to conform to whatever RFC we agree to for OAM processing.

Second, there appears to be no description of any case where the O bit 
is used.  All of the examples seem to use the END.OP and END.OTP 
processing instructions.  Since the O_bit definition is clear that the 
upper layer protocol is NOT to be processed, what is the processing to 
be performed when the O bit is set?

Related to the above, given that the O-bit definition and the END.OP / 
END.OTP both over-write the S01 step, what is to happen if both are true?

Minor:
     I presume that both over-writes for the S01 step of the SRH are 
intended to retain the base document "When an SRH is processed" text? 
If so, given that they say they replace that step, the caveat needs to 
be included.

    It looks like one side-effect of END.OP is that once could actually 
establish communication (TCP or UDP) with a node by addressing it at its 
END.OP SID?  (Presumably from another node inside the SR Domain?)

     Also, it looks like END.OP and END.OTP both cause termination of 
the SID processing.  I believe it would be helpful to be more explicit 
about this.

Yours,
Joel

On 12/18/2019 7:01 PM, Zafar Ali (zali) wrote:
> Hi Joel,
> 
> Thanks for your review.
> 
> The processing details were embedded in the Section 4.
> 
> We brought them up in the Section 3 and also added additional normative 
> language in Section 4.
> 
> We have been maintaining the latest version of the draft in the Github.
> 
> However, we also posted the latest diffs, which addresses your comments 
> as follows:
> 
>   * In the new revision, we have added normative text at the beginning
>     of 3.1.1 where O-bit is defined.
>   * Sections 3.3 and 3.4 adds normative texts for OAM SIDs.
>   * 4.1.2 and 4.2.2 further adds additional normative text for Ping and
>     traceroute use-cases, respectively. 
> 
> Latest version is kept in the Github and also uploaded as 
> https://www.ietf.org/staging/draft-ietf-6man-spring-srv6-oam-03.txt.
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *"Joel M. Halpern" <[e-mail]>
> *Date: *Thursday, December 5, 2019 at 10:01 PM
> *To: *"Zafar Ali (zali)" <[e-mail]>, 6man WG <[e-mail]>, 
> SPRING WG <[e-mail]>
> *Subject: *Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
> 
> Sorry, minor typo.  SRH, not NSH, in the 4th paragraph.
> 
> Joel
> 
> On 12/5/2019 9:42 PM, Joel M. Halpern wrote:
> 
>     The normative behavior for the bits in various places says that the
> 
>     packet is punted to the control process.  In and of itself, that is
>     fine.
> 
>     However, in order for that to be useful, the control process has to
>     know
> 
>     what to do with the packet when it gets there.  In the classic case of
> 
>     router redirect, this is coupled with definition of various content to
> 
>     be processed by the router control logic.
> 
>     In the case of this document, there is no normative definition of what
> 
>     the control process is to do with the packet.  And particularly
>     since in
> 
>     many of the cases described the packet that is punted still has an SRH,
> 
>     normal packet processing would simply reach the same "punt" step.  With
> 
>     nowhere to punt it.
> 
>     You asssume in the examples that some forms of parsing that bypass the
> 
>     NSH will take place.  But processing does not take place by instinct or
> 
>     magic.  It takes place because we write RFCs that describe what has to
> 
>     happen.  Without some definition of the required parsing, and I believe
> 
>     (although I am guessing due to the lack of description) we also need
> 
>     some normative description of what the control process is required
>     to do.
> 
>     Note that in most OAM, we define the behavior that is required, and
>     then
> 
>     indicate where it is permitted to use the control plane to achieve it.
> 
>     This results in a clear specification, and implementation flexibility.
> 
>     Yours,
> 
>     Joel
> 
>     On 12/5/2019 9:34 PM, Zafar Ali (zali) wrote:
> 
>         Hi Joel,
> 
>         I did not understand your comment.
> 
>         Can you please point to specific text in the draft for which the
>         draft
> 
>         needs to define normative behavior for the "node punt processor
>         look
> 
>         past the SRH and make determinations based on the content."?
> 
>         Thanks
> 
>         Regards … Zafar
> 
>         *From: *ipv6 <[e-mail]
>         <mailto:[e-mail]>> on behalf of "Joel M. Halpern"
> 
>         <[e-mail] <mailto:[e-mail]>>
> 
>         *Date: *Wednesday, December 4, 2019 at 4:37 PM
> 
>         *To: *Ole Troan <[e-mail]
>         <mailto:[e-mail]>>, 6man WG <[e-mail]
>         <mailto:[e-mail]>>,
> 
>         SPRING WG <[e-mail] <mailto:[e-mail]>>
> 
>         *Subject: *Re: 6man w.g. last call for
>         <draft-ietf-6man-spring-srv6-oam>
> 
>         I re-read this draft, and I am afraid it is currently
>         under-specified.
> 
>         In order for the various examples to work, there is assumed
>         behavior by
> 
>         the processor to which packets are punted.  I could not find
>         where this
> 
>         normative behavior is described explicitly.  It appears that the
> 
>         behavior requires that the node "punt processor" look past the
>         SRH and
> 
>         make determinations based on the content.  This needs to be
>         described
> 
>         explicitly.  And it needs some discussion of why it is legitimate to
> 
>         look past the SRH when the SRH does not show SL=0.
> 
>         Yours,
> 
>         Joel
> 
>         On 12/4/2019 3:53 PM, Ole Troan wrote:
> 
>              Hello,
> 
>                   As agreed in the working group session in Singapore, this
> 
>              message starts a new two week 6MAN Working Group Last Call on
> 
>         advancing:
> 
>                   Title    : Operations, Administration, and Maintenance
>         (OAM) in
> 
>              Segment Routing Networks with IPv6 Data plane (SRv6)
> 
>                   Author   : Z. Ali, C. Filsfils, S. Matsushima, D.
>         Voyer, M. Chen
> 
>                   Filename : draft-ietf-6man-spring-srv6-oam-02
> 
>                   Pages    : 23
> 
>                   Date     : 2019-11-20
> 
>         https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
> 
>              as a Proposed Standard.
> 
>              Substantive comments and statements of support for
>         publishing this
> 
>              document should be directed to the mailing list.
> 
>              Editorial suggestions can be sent to the author. This last
>         call will
> 
>              end on the 18th of December 2019.
> 
>              To improve document quality and ensure that bugs are caught
>         as early
> 
>              as possible, we would require at least
> 
>              two reviewers to do a complete review of the
>         document.  Please let
> 
>              the chairs know if you are willing to be a reviewer.
> 
>              The last call will be forwarded to the spring working
>         group, with
> 
>              discussion directed to the ipv6 list.
> 
>              Thanks,
> 
>              Bob & Ole, 6man co-chairs
> 
>             
>         --------------------------------------------------------------------
> 
>              IETF IPv6 working group mailing list
> 
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> 
>              Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
> 
>             
>         --------------------------------------------------------------------
> 
>         --------------------------------------------------------------------
> 
>         IETF IPv6 working group mailing list
> 
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> 
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>         --------------------------------------------------------------------
> 
>     --------------------------------------------------------------------
> 
>     IETF IPv6 working group mailing list
> 
>     [e-mail] <mailto:[e-mail]>
> 
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>     --------------------------------------------------------------------
>