Re: [spring] Different MSDs for different traffic types on the same headend.

Thank you Jeff for taking the time for the detailed response!! Cheers & Happy Holidays!! Gyan On Wed, Dec 18, 2019 at 7:13 PM Jeff Tantsura wrote: > Pleasure, see inline > /*somewhat philosophical ;-) > > Cheers, > Jeff > On Dec 17, 2019, 10:28 PM -0800, Gyan Mishra , > wrote: > > > Thanks

[spring] FW: New Version Notification for draft-ietf-6man-spring-srv6-oam-03.txt

Dear 6man and Spring, This revision addressed comments received during the last call, as detailed in our responses to the comments. As per the chair’s direction, we have been maintaining the latest version at https://github.com/ietf-6man/srv6-oam. Thanks Regards … Zafar From:

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

Hi Zhenqiang, Many thanks for your comments. We have been maintaining the latest version of the draft in the Github to address all comments. However, we just posted revision 3. Add editorial comments has been fixed. For non-editorial comments, please see in-line. Thanks Regards … Zafar From:

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

Hi Greg, Many thanks for your detailed comments. Much appreciated. Please see comments in-line and how the new version addresses your comments. I also look forward to our offline discussion on Friday. Please note we have been also maintaining the latest version of the draft in the 6man-Github.

Re: [spring] Different MSDs for different traffic types on the same headend.

Pleasure, see inline /*somewhat philosophical ;-) Cheers, Jeff On Dec 17, 2019, 10:28 PM -0800, Gyan Mishra , wrote: > > Thanks Jeff!! > > Kind regards > > I have a personal Cisco VIRL server server which I just finished building out > the SP topology with two SP SR domains.  Cisco XRv supports

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] 64-bit locators

On Thu, 19 Dec 2019, 04:16 Ron Bonica, wrote: > Folks, > > > > I am warming to the idea of fix-length, > I think fixed length or single size is always a good thing to aim for. RFC5505, although about host configuration, sums it up the benefits very well. "Anything that can be configured can

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] packet captures for draft-ietf-spring-srv6-network-programming-06?

Le 18/12/2019 à 21:59, Andrew Alston a écrit : > /RP/0/RP0/CPU0:SRV6-R2#show segment-routing srv6 locator R2 sid Sun Dec > 15 04:56:10.913 UTC/ > > /SID Behavior > Context Owner State RW/ > >

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Le 18/12/2019 à 21:53, Andrew Alston a écrit : > I would like to ask you whether that 2001:db8:ee:2:1:: could rather be 2001:db8:ee:ff:2:1::? No - the locator has to be on a 64bit boundary - it refuses configuration for anything else in the code bases I have tested

Re: [spring] 64-bit locators

Le 18/12/2019 à 18:16, Ron Bonica a écrit : Folks, I am warming to the idea of fix-length, 64-bit locators. Benefits follow: * There is no use-case for less specific (e.g., /56) locators * It would make the FUNC part of the address appear in a predictable location. This would

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] packet captures for draft-ietf-spring-srv6-network-programming-06?

>> /RP/0/RP0/CPU0:SRV6-R2#show segment-routing srv6 locator R2 sid Sun Dec >> 15 04:56:10.913 UTC/ >> >> /SID Behavior >> Context Owner State RW/ >> >> /-- --- >

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

> I would like to ask you whether that >2001:db8:ee:2:1:: >could rather be >2001:db8:ee:ff:2:1::? No - the locator has to be on a 64bit boundary - it refuses configuration for anything else in the code bases I have tested on. Thanks Andrew

[spring] 64-bit locators

Folks, I am warming to the idea of fix-length, 64-bit locators. Benefits follow: * There is no use-case for less specific (e.g., /56) locators * It would make the FUNC part of the address appear in a predictable location. This would facilitate ACLs that match on function. While you

Re: [spring] IPR poll for draft-ietf-spring-srv6-network-programming

Hi, As a contributor , I’m not aware of any undisclosed IPR related to this document. Sensitivity: Internal Use Only -Original Message- From: bruno.decra...@orange.com Sent: Thursday, December 5, 2019 5:50 PM To: 'SPRING WG List' ; draft-ietf-spring-srv6-network-programming

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Andrew, Le 17/12/2019 à 06:57, Andrew Alston a écrit : Alex, Will try and get you some captures off the devices I’ve been testing on – in order to make sure I understood this draft properly, and in light of the deployment status draft, I decided to play a lot more deeply and setup a bit of

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Excuse me for posting in reply interspersed to someone else. It's because I did not get the original from R. Raszuk. Le 17/12/2019 à 11:59, Mark Smith a écrit : On Tue, 17 Dec 2019, 21:12 Robert Raszuk, > wrote: Hi Andrew, My personal opinion is that with below

Re: [spring] USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt

well, I went through again some sections about specific SIDs definition in last draft, I feel that SRH processing module (pseudocode module) include outright all kinds of EHs processing. OK. Cheers! Wang Weibin From: Wang, Weibin (NSB - CN/Shanghai) Sent: 2019年12月18日 16:08 To:

Re: [spring] USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt

Hi SPRING WG and authors: I need in further express my opinion about USD SID. From the content in this last draft, I find lots of SIDs defined in draft, such as END.DX, END.DT, END.DX2 etc., which imply in fact that the next-header immediately following SRH being processed are upper-layer