Hi Greg,
The END.OTP SID is NOT defined or to be used for in-situ OAM.
Thanks
Regards … Zafar
*From: *ipv6 <ipv6-boun...@ietf.org> on behalf of Greg Mirsky
<gregimir...@gmail.com>
*Date: *Thursday, December 19, 2019 at 10:21 AM
*To: *Robert Raszuk <rob...@raszuk.net>
*Cc: *SPRING WG <spring@ietf.org>, 6man WG <i...@ietf.org>
*Subject: *Re: [spring] 6man w.g. last call for
<draft-ietf-6man-spring-srv6-oam> - END.OTP
Hi Robert,
thank you for your quick response. Could you please help me understand
how this proposed mechanism complements what is defined in the
combination of iOAM data
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-08> and iOAM in
IPv6 <https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-00>
drafts? As I understand it, the data draft already includes the
mechanism to trigger the timestamp collection on a node by setting the
appropriate flags in the IOAM-Trace-Type field. And the IOAM-Trace-Type
field is part of iOAM in IPv6 encapsulation. If that is the case, I
don't see the gap that needs to be closed but the duplication of
functionality by the proposed END..OTP function.
Regards,
Greg
On Thu, Dec 19, 2019 at 7:06 AM Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk..net>> wrote:
Hi Greg,
> I believe that iOAM already has defined a method to collect
timestamps
> and the method to trigger timestamping described in the draft we're
> discussing is duplicating that. Would you agree?
Nope not at all.
The timestamping is needed in the SR paths in the outer header. iOAM
says:
Scope: This document defines the data fields and associated data
types for in-situ OAM. The in-situ OAM data field can be
transported
by a variety of transport protocols, including NSH, Segment Routing,
Geneve, IPv6, or IPv4. * Specification details for these different*
* transport protocols are outside the scope of this document.*
I think current SR OAM draft fills that gap.
Thx
R.
On Thu, Dec 19, 2019 at 3:49 PM Greg Mirsky <gregimir...@gmail.com
<mailto:gregimir...@gmail.com>> wrote:
Hi Robert,
could you please clarify your statement "there is huge value
in defining packet timestamping in all oam documents IETF
produces these days"? Is that applicable to Active OAM methods
or to other OAM methodologies, including, Passive and Hybrid? If
the timestamping operation is entirely local to a networking
node is applied to a data flow, in other words, the timestamp
value is not stored in the forwarded downstream data packet,
which performance metric your expect to produce? Or is the
expectation to use the Alternate Marking methodology, as
described in RFC 8321, in combination with the local
timestamping? If the product of the timestamping operation is
stored in the data packet, then how is that different from what
is already described in the iOAM draft you've referenced? I
believe that iOAM already has defined a method to collect
timestamps and the method to trigger timestamping described in
the draft we're discussing is duplicating that. Would you agree?
Regards,
Greg
On Thu, Dec 19, 2019 at 1:56 AM Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>> wrote:
Hi Joel,
> However, there is no defined behavior that I know of
that can make use
> of this timestamp.
Not sure how to read that statement. Are you expecting IETF
draft to tell vendor that computing delta of N values is
needed ? Or is IETF draft needed to tell packet analyzers to
evaluate the quality of the path based on packets timestamps
? Yes routers may never be involved in such processing, but
other network monitoring components do.
Sure current networking in this regard is in stone ages, but
there are real efforts and working code which goes beyond
that already in place. Example:
https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-08
So there is huge value in defining packet timestamping in
all oam documents IETF produces these days and it would be
rather disservice to remove such important option.
Thx,
r.
On Thu, Dec 19, 2019 at 1:45 AM Joel M. Halpern
<j...@joelhalpern.com <mailto:j...@joelhalpern.com>> wrote:
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
<mailto:j...@joelhalpern.com>>
> *Date: *Thursday, December 5, 2019 at 10:01 PM
> *To: *"Zafar Ali (zali)" <z...@cisco.com
<mailto:z...@cisco.com>>, 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>
>
> 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>
> <mailto:ipv6-boun...@ietf.org
<mailto:ipv6-boun...@ietf.org>>> on behalf of "Joel M.
Halpern"
>
> <j...@joelhalpern.com
<mailto:j...@joelhalpern...com>
<mailto: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>
> <mailto:otr...@employees.org
<mailto:otr...@employees.org>>>, 6man WG <i...@ietf.org
<mailto:i...@ietf.org>
> <mailto:i...@ietf.org <mailto:i...@ietf.org>>>,
>
> SPRING WG <spring@ietf.org
<mailto:spring@ietf.org> <mailto: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 <mailto: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 <mailto: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 <mailto:i...@ietf.org>>
>
> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
>
>
--------------------------------------------------------------------
>
_______________________________________________
spring mailing list
spring@ietf.org <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
--------------------------------------------------------------------
IETF IPv6 working group mailing list
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
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
