If I am reading the draft correctly, the difference between END.OP and
END.OTP is that an internal process is to attach in some internal
location a timestamp to the packet. In the abstract, I understand why
such cna be useful.
However, there is no defined behavior that I know of that can make use
of this timestamp. Until such a behavior is defined, what is the value
in defining the END.OTP behavior? (Taken in the extreme, until there is
such a definition, any implementation which treated END.OTP as END.OP
would seem to be indistinguishable from proper operation in terms of
behavior on the wire.)
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" <j...@joelhalpern.com>
*Date: *Thursday, December 5, 2019 at 10:01 PM
*To: *"Zafar Ali (zali)" <z...@cisco.com>, 6man WG <i...@ietf.org>,
SPRING WG <spring@ietf.org>
*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 <ipv6-boun...@ietf.org
<mailto:ipv6-boun...@ietf.org>> on behalf of "Joel M. Halpern"
<j...@joelhalpern.com <mailto:j...@joelhalpern.com>>
*Date: *Wednesday, December 4, 2019 at 4:37 PM
*To: *Ole Troan <otr...@employees.org
<mailto:otr...@employees.org>>, 6man WG <i...@ietf.org
<mailto:i...@ietf.org>>,
SPRING WG <spring@ietf.org <mailto:spring@ietf.org>>
*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
i...@ietf.org <mailto:i...@ietf.org> <mailto:i...@ietf.org>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org <mailto:i...@ietf.org> <mailto:i...@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org <mailto:i...@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
