Re: [spring] 6man w.g. last call for

r > > > > *From: *"Zafar Ali (zali)" > *Date: *Wednesday, December 18, 2019 at 7:19 PM > *To: *Greg Mirsky , Ole Troan > > *Cc: *SPRING WG , 6man WG , 6man Chairs < > 6man-cha...@ietf.org>, "Zafar Ali (zali)" > *Subject: *Re: [spring] 6man

Re: [spring] 6man w.g. last call for

word document diffs (privately). But either way, your comments are quite clear. Many Thanks Regards … Zafar *From: *"Zafar Ali (zali)" *Date: *Thursday, January 23, 2020 at 6:46 PM *To: *Loa Andersson , Brian E Carpenter , Ole Troan , 6man WG , SPRING WG *Cc: *6man Chairs &

Re: [spring] 6man w.g. last call for

I will reach-out to you > again to discuss your comments. > > > > Thanks > > > > Regards … Zafar > > > > *From: *"Zafar Ali (zali)" > *Date: *Wednesday, December 18, 2019 at 7:19 PM > *To: *Greg Mirsky , Ole Troan > > *Cc: *SPRING W

Re: [spring] 6man w.g. last call for

-ietf-spring-srv6-network-programming Asunto: Re: [spring] 6man w.g. last call for Hi Greg, I went back to your comments to verify the latest version in the GitHub addresses them (as marked by [ZA]). This is with the exception of your question on handling of BFD control packets or STAMP test

Re: [spring] 6man w.g. last call for

Regards … Zafar From: "Zafar Ali (zali)" Date: Wednesday, December 18, 2019 at 7:19 PM To: Greg Mirsky , Ole Troan Cc: SPRING WG , 6man WG , 6man Chairs <6man-cha...@ietf.org>, "Zafar Ali (zali)" Subject: Re: [spring] 6man w.g. last call for Hi Greg, Many thanks

Re: [spring] 6man w.g. last call for

Zafar Ali (zali)" Date: Thursday, January 23, 2020 at 6:46 PM To: Loa Andersson , Brian E Carpenter , Ole Troan , 6man WG , SPRING WG Cc: 6man Chairs <6man-cha...@ietf.org>, "Zafar Ali (zali)" Subject: Re: [spring] 6man w.g. last call for Loa, Many thanks. The comme

Re: [spring] 6man w.g. last call for

Ole Troan , 6man WG , SPRING WG Cc: 6man Chairs <6man-cha...@ietf.org> Subject: Re: [spring] 6man w.g. last call for Zafar, Tnx - 1 down 36 to go! Actually a bit more with the NITs output. Can you take a look at the long lines next, it should be easy edits. The firs

Re: [spring] 6man w.g. last call for

ING WG *Cc: *6man Chairs <6man-cha...@ietf.org> *Subject: *Re: [spring] 6man w.g. last call for Zafar, Thanks for addressing this. However one thing remains. The text is now: "There MAY be additional segments preceding the END.OP/ END.OTP SID." I don't think there is a need f

Re: [spring] 6man w.g. last call for

man Chairs <6man-cha...@ietf.org> Subject: Re: [spring] 6man w.g. last call for Zafar, Thanks for addressing this. However one thing remains. The text is now: "There MAY be additional segments preceding the END.OP/ END.OTP SID." I don't think there is a need for requirement languag

Re: [spring] 6man w.g. last call for

WG , SPRING WG *Cc: *6man Chairs <6man-cha...@ietf.org> *Subject: *Re: [spring] 6man w.g. last call for To be clear about one of the points in the review, MAY NOT is not allowed by RFC2119 because it is totally ambiguous in English (since it can mean either "must not" or "

Re: [spring] 6man w.g. last call for

:49 PM To: "Zafar Ali (zali)" , Ole Troan , 6man WG , SPRING WG Cc: 6man Chairs <6man-cha...@ietf.org> Subject: RE: [spring] 6man w.g. last call for Hi Ali, I have review what I believe to be the latest version (in github) and have the following comments: Major ---

Re: [spring] 6man w.g. last call for

: University of Auckland Date: Monday, January 20, 2020 at 2:57 PM To: Loa Andersson , Ole Troan , 6man WG , SPRING WG Cc: 6man Chairs <6man-cha...@ietf.org> Subject: Re: [spring] 6man w.g. last call for To be clear about one of the points in the review, MAY NOT is not allowed by RFC2119 b

Re: [spring] 6man w.g. last call for

Loa, Thanks, that is very helpful. Bob > On Jan 20, 2020, at 6:20 PM, Loa Andersson wrote: > > Bob, > > > Here is the docx-file, it is not exactly the same version as I used to > create the txt-file, since I continued to look at the figure for the > reference topology, and in that process

Re: [spring] 6man w.g. last call for

Bob, Here is the docx-file, it is not exactly the same version as I used to create the txt-file, since I continued to look at the figure for the reference topology, and in that process I also corrected a spelling erros and cleared up the text for some comments. The only real change is that I

Re: [spring] 6man w.g. last call for

To be clear about one of the points in the review, MAY NOT is not allowed by RFC2119 because it is totally ambiguous in English (since it can mean either "must not" or "might not"). In any case the phrase "MAY or MAY NOT" is not of any normative value. It presumably simply means "MAY" in all

Re: [spring] 6man w.g. last call for

Hinden Date: Monday, January 20, 2020 at 6:13 AM To: Loa Andersson Cc: IPv6 List , Ole Trøan , Bob Hinden , SPRING WG , 6man Chairs <6man-cha...@ietf.org> Subject: Re: [spring] 6man w.g. last call for Loa, Thanks for doing the review. I think it may be worthwhile to also se

Re: [spring] 6man w.g. last call for

Loa, Thanks for doing the review. I think it may be worthwhile to also send out the .docx file in addition to the text version. Bob > On Jan 19, 2020, at 11:54 PM, Loa Andersson wrote: > > WG, > > I have reviewed the entire document. > > First, I'm not an IPv6 expert. > > As far as I

Re: [spring] 6man w.g. last call for

WG, I have reviewed the entire document. First, I'm not an IPv6 expert. As far as I can see the sued on I have not used github, I had a couple of attempts to learn the tools, but so far I have failed. I have instead done what I use to do, use the review tool with Word. Since I sometimes

Re: [spring] 6man w.g. last call for

G , SPRING WG Cc: 6man Chairs <6man-cha...@ietf.org> Subject: RE: [spring] 6man w.g. last call for Hi Ali, I have review what I believe to be the latest version (in github) and have the following comments: Major * A close reading of Section 3.1.1 reveals that the O-flag is

Re: [spring] 6man w.g. last call for

as the ENH. Juniper Business Use Only From: Zafar Ali (zali) Sent: Friday, December 20, 2019 10:42 AM To: Ron Bonica ; Ole Troan ; 6man WG ; SPRING WG Cc: 6man Chairs <6man-cha...@ietf.org>; Zafar Ali (zali) Subject: Re: [spring] 6man w.g. last call for Hi Ron, Thanks for your review

Re: [spring] 6man w.g. last call for - END.OTP

Hi Greg, Joel, We can add clarification text. Happy Holidays! Thanks Regards … Zafar From: Greg Mirsky Date: Thursday, December 19, 2019 at 12:44 PM To: "Zafar Ali (zali)" Cc: Robert Raszuk , SPRING WG , 6man WG Subject: Re: [spring] 6man w.g. last call for - END.OTP Hi Za

Re: [spring] 6man w.g. last call for

: spring on behalf of Ron Bonica Date: Wednesday, December 18, 2019 at 4:07 PM To: Ole Troan , 6man WG , SPRING WG Cc: 6man Chairs <6man-cha...@ietf.org> Subject: Re: [spring] 6man w.g. last call for Ole, I have reviewed version-02 of this document and believe that it still has the following

Re: [spring] 6man w.g. last call for - END.OTP

*To: *Robert Raszuk > *Cc: *SPRING WG , 6man WG > *Subject: *Re: [spring] 6man w.g. last call for > - 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 th

Re: [spring] 6man w.g. last call for - END.OTP

Ali (zali) wrote: Hi Greg, The END.OTP SID is NOT defined or to be used for in-situ OAM. Thanks Regards … Zafar *From: *ipv6 on behalf of Greg Mirsky *Date: *Thursday, December 19, 2019 at 10:21 AM *To: *Robert Raszuk *Cc: *SPRING WG , 6man WG *Subject: *Re: [spring] 6man w.g.

Re: [spring] 6man w.g. last call for - END.OTP

Hi Greg, The END.OTP SID is NOT defined or to be used for in-situ OAM. Thanks Regards … Zafar From: ipv6 on behalf of Greg Mirsky Date: Thursday, December 19, 2019 at 10:21 AM To: Robert Raszuk Cc: SPRING WG , 6man WG Subject: Re: [spring] 6man w.g. last call for - END.OTP Hi Robert

Re: [spring] 6man w.g. last call for - END.OTP

Rakesh, I appreciate the pointers. However, I believe some clarification is in order. RFC 5357 does not use END.OTP. It does not mention END.OTP. It can't, since END.OTP did not exist when it was written. Your individual draft on twamp does reference END.OTP. This leads to two possible

Re: [spring] 6man w.g. last call for - 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 and iOAM in IPv6

Re: [spring] 6man w.g. last call for - END.OTP

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:

Re: [spring] 6man w.g. last call for - END.OTP

Hi Rakesh, thank you for pointing to this interesting proposal. But, as I understand RFC 5357 and Appendix I, timestamp collection is already part of the TWAMP. Why there's the need to duplicate what is being documented in RFC 5357? Regards, Greg On Thu, Dec 19, 2019 at 6:57 AM Rakesh Gandhi

Re: [spring] 6man w.g. last call for - END.OTP

Hi Greg, Joel, FYI, END.OTP is used with TWAMP Light (RFC 5357) (and STAMP) in draft-gandhi-spring-twamp-srpm and RFC 6374 in draft-gandhi-spring-rfc6374-srpm-udp, for performance delay measurement use-case. thanks, Rakesh On Thu, Dec 19, 2019 at 9:49 AM Greg Mirsky wrote: > Hi Robert, >

Re: [spring] 6man w.g. last call for - END.OTP

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

Re: [spring] 6man w.g. last call for - END.OTP

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

Re: [spring] 6man w.g. last call for - END.OTP

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

Re: [spring] 6man w.g. last call for

: spring on behalf of "li_zhenqi...@hotmail.com" Date: Friday, December 6, 2019 at 3:14 AM To: Ole Troan , "i...@ietf.org" , "spring@ietf.org" Cc: 6man Chairs <6man-cha...@ietf.org> Subject: Re: [spring] 6man w.g. last call for Hello Ole an

Re: [spring] 6man w.g. last call for

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.

Re: [spring] 6man w.g. last call for

. Thanks Regards … Zafar From: spring on behalf of Greg Mirsky Date: Thursday, December 5, 2019 at 5:22 PM To: Ole Troan Cc: SPRING WG , 6man WG , 6man Chairs <6man-cha...@ietf.org> Subject: Re: [spring] 6man w.g. last call for Dear Authors, et al., please find my comments, as

Re: [spring] 6man w.g. last call for

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

Re: [spring] 6man w.g. last call for

Hi Ron, Thank you, the last call for this document will stay open until the issues raised are closed. Currently we are awaiting a new revision from the authors. I expect a few more rounds on this one. Best regards, Ole > On 18 Dec 2019, at 22:07, Ron Bonica wrote: > > Ole, > > I have

Re: [spring] 6man w.g. last call for

Ole, I have reviewed version-02 of this document and believe that it still has the following major issues: - Section 3.1.1 assumes implementation details (e.g., that the implementation has an OAM process) but fails to describe any externally observable behavior. The externally observable

Re: [spring] 6man w.g. last call for

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

Re: [spring] 6man w.g. last call for

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

Re: [spring] 6man w.g. last call for

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 on behalf

Re: [spring] 6man w.g. last call for

Dear Authors, et al., please find my comments, as WG LC comments, questions to this document below. - The Abstract and Introduction describe the document as "defines building blocks for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane

Re: [spring] 6man w.g. last call for

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

[spring] 6man w.g. last call for

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,