Re: [spring] Administrative interfaces (was draft-filsfilscheng-spring-srv6-srh-compression)

All, I must say that I am not quite sure what is being discussed here. Today the computer node says linux is also called host. That host has in the kernel multiple routing tables. The same very host (or node) is a home for the number of kube pods which in turn are home for the number of contain

Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

Nick & Sander, Just for my own understanding here. A) Are you asking to add new TLV to IPv6 SRH say called "C-SID Length" (and make SRH mandatory if used with C-SIDs) which would define the C-SID length ? or B) Are you asking to define a completely new data plane for IP networks ? By new data

Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

On Sun, Oct 24, 2021 at 11:48 PM Mark Smith wrote: > Subnet masks weren't a good idea either. They, like classes and CIDR, are > hacks to squeeze more addresses out of the 32 bit IPv4 address space. > > Have a look at the IPv4 address structure in RFC760. Couldn't be simpler. > Simplicity ofte

Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

Hello John, May I inquire what was not definitive as part of my answer ? Please observe that below documents which are product of this WG go in depth to evaluate compression against the requirement not to change SRv6 data plane: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compres

Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

John. Many thx, R. On Tue, Oct 26, 2021 at 10:01 PM Ron Bonica wrote: > Robert, > > > > Which requirement was that? > > > > Ron > > > > > > > > Juniper Business Use Only > > *From:* spring *On Behalf Of *R

Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

der wrote: > Hi Robert, > > > On Oct 26, 2021, at 3:41 PM, Robert Raszuk wrote: > > > > Hello John, > > > > May I inquire what was not definitive as part of my answer ? > > I answered that in my response to your earlier message: > https://mail

Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

vendors and operators are investing in the technology especially when it comes out of IETF as Standards Track formal RFC. Kind regards, Robert Raszuk PS. I think you have perhaps accidently violated the IETF process. And not in regards to compression draft. But in respect to effectively asking

Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

> I am not attempting to revisit the question of whether RFC 8986 complies > with RFC 4191. > This compression documents raises additional issues beyond those in 8986 > in some aspects of the flavors it describes. Could you be so kind and enumerate where in the draft you see *anything* crossing t

Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

> Joel > > On 10/31/2021 2:31 PM, Robert Raszuk wrote: > > > > I am not attempting to revisit the question of whether RFC 8986 > > complies > > with RFC 4191. > > This compression documents raises additional issues beyond those in > > 8986

Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

Dear Joel, It is clear that your personal view of the relevance of SID ARG content to IPv6 address differs from the view of many WG participants. To be very clear - whatever SPRING WG decides to put into SID ARG field it is completely orthogonal to IPv6 community as it has completely nothing to d

Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

call, the issue of the > relationship between C-SIDs and RFC 4291 was raised in such a way that I > concluded that even if I did not agree with the issue I would have to > recognize that it needed to be addressed. > > Yours, > Joel > > On 11/5/2021 2:46 PM, Robert Raszuk wr

Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

Hi John, The point, again, is that by introducing a way for an attacker to cause a > target system to display arbitrary strings, it would seem reasonable to > wonder if that creates an opportunity for mischief that doesn’t ordinarily > exist in our protocols, involving misleading people looking at

Re: [spring] Segment Routing in Two Dimensional IP Routing

Hi Bo, Few questions ... 1. How do you envision remote endpoints would know the src IP information ? 2. How can flooded or p2mp distributed information containing src addresses of the packets valid in many ingress sites ? Please observe that each ingress site would be very likely using a differe

Re: [spring] [Idr] New draft "draft-hr-spring-intentaware-routing-using-color"

ay a P node role. Many thx, R. On Sun, Jul 17, 2022 at 12:10 PM Dhananjaya Rao (dhrao) wrote: > Hi Robert, > > > > Thank you for the rapid review and insightful comments, as usual. > > > > Please see inline (DR##) > > > > *From: *Robert Raszuk > *Date: *

Re: [spring] Proposed policy on reporting implementation and interoperability

Hi Joel, First thank you & AD for initiating this. Two questions/comments below: #1: > 2) Each implementation description MUST include either a statement that > all MUST clauses in the draft / RFC are implemented, or a statement as to > which ones are not implemented. > How can you allow any i

Re: [spring] Proposed policy on reporting implementation and interoperability

capture the snapshot. If people > want to separately maintain web pages, I am sure we can get the pages set > up to complement this effort. > > Yours, > > Joel > On 8/12/2022 6:00 PM, Robert Raszuk wrote: > > Hi Joel, > > First thank you & AD for initiati

Re: [spring] Proposed policy on reporting implementation and interoperability

Hi Jeff, > I’d expect to see all and each MUST statements implemented for an > implementation to be able to claim to be 100% compliant with the specification. Glad we agree on that. But my point was not so much to claim 100% compliance or 90% compliance. My point was that any report which indica

Re: [spring] Proposed policy on reporting implementation and interoperability

folks do > report such partial compliance, it is helpful to include it. Whether > anyone will make such a report remains to be seen. > > Yours, > > Joel > On 8/13/2022 1:56 PM, Robert Raszuk wrote: > > Hi Jeff, > > > I’d expect to see all and each MUST statement

Re: [spring] Proposed policy on reporting implementation and interoperability

Joel, > I would be interested in hearing from the WG on this. My expectations is > that if someone says they implement optional feature X, and X has MUSTs > conditioned on it, then they have to explain whether they comply with those > MUSTs. > When I look at BCP-14 or RFC2119 I do not see any dis

Re: [spring] Proposed policy on reporting implementation and interoperability

So it seems useful to recognize that reality. > > Yours, > > Joel > On 8/19/2022 10:58 AM, Robert Raszuk wrote: > > Joel, > >> I would be interested in hearing from the WG on this. My expectations is >> that if someone says they implement optional feature X,

Re: [spring] Proposed policy on reporting implementation and interoperability

or SR. However, there are > some MUST clauses to follow should implementation support it. > > I hope that clarifies. > > Thanks, > Ketan > > > On Fri, Aug 19, 2022 at 9:01 PM Robert Raszuk wrote: > >> Hi Joel, >> >> Would you mind providing a few su

Re: [spring] Proposed policy on reporting implementation and interoperability

l, but should one implement > their support, they would need to deal with some MUST clauses specific to > those advertisements and their processing. > > Thanks, > Ketan > > > On Fri, Aug 19, 2022 at 9:18 PM Robert Raszuk wrote: > >> Thx Ketan. >> >> Yes in

Re: [spring] Proposed policy on reporting implementation and interoperability

Hi Adrian, I 100% agree with you. However what I understood as "Implementation Section" requirement was as simple a one paragraph including URL to an IETF wiki page. Not actual list of vendors and features supported. That would be highly inaccurate the moment it is posted. Many thx, Robert On

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Gyan, SRv6 could use ULA if it would start and stop within "limited domain". But concept of SRv6 is from day one extended to start and end on end systems (user's host, mobile device, sensor etc ...) hence in those deployments is must use GUA. And with that if we are to use GUA in one case we cou

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Hi Suresh, NEW: > In case the deployments do not use this allocated prefix additional care > needs to be exercised at network ingress and egress points so that SRv6 > packets do not leak out of SR domains and they do not accidentally enter SR > unaware domains. > IMO this is too broad. I would sa

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

o way a domain can apply incorrect filtering. > > Yours, > > Joel > On 10/8/2022 3:16 AM, Robert Raszuk wrote: > > Hi Suresh, > > NEW: >> In case the deployments do not use this allocated prefix additional care >> needs to be exercised at network ingress and

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

; specifications need to conform to that. > > Yours, > > Joel > On 10/8/2022 2:52 PM, Robert Raszuk wrote: > > Hi Joel, > > I was hoping this is apparent so let me restate that I do not buy into > "limited domain" business for SRv6. > > I have N sites con

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

gt; Regards > Brian Carpenter > > On 09-Oct-22 07:52, Robert Raszuk wrote: > > Hi Joel, > > > > I was hoping this is apparent so let me restate that I do not buy into > "limited domain" business for SRv6. > > > > I have N sites connected over v6 I

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

oofing means there is little way to tell whether an > unencapsulated packet actually came from another piece of the same domain. > > So yes, I think making this restriction clear in this RFC is important and > useful. > > Yours, > > Joel > On 10/8/2022 5:07 PM, Robert Ra

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

tions based on that property that > the RFCs require. > > Yours, > > Joel > On 10/9/2022 10:49 AM, Robert Raszuk wrote: > > Joel, > > > it turns SRH into a powerful attack vector > > Really ? > > How is this possible if IPv6 destination address of th

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

to do so and as you say below we can only > provide recommendations. > > Regards > Suresh > > On Oct 9, 2022, at 11:42 AM, Robert Raszuk wrote: > > Joel, > > > You can't tell a packet validly from another piece of your domain from a > packet being > &

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Hi Brian, Easily avoided by another layer of encapsulation, surely? Personally I > would want to do that, and to use an encrypted encapsulation, to make sure > that the SR domain is not penetrated. > I am not even sure what you call SR domain ... In the old days, slides showed the domain as a lit

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

course, this email and the previous one are written without any hat > and are not related to Suresh's I-D. > > > > Regards > > > > -éric > > > > > > *From: *Joel Halpern > *Date: *Monday, 10 October 2022 at 15:36 > *To: *Eric Vyncke ,

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

> it seems acceptable to block all packets with SRH And such statements you are making are exactly my point. Just curious - Is there any other extension header type subject to being a good enough reason to drop packets at any transit node in IPv6 ? Thx, R. On Mon, Oct 10, 2022 at 3:53 PM Joel

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

have said that you consider the limited domain requirement to be wrong > and irrelevant. Whether you agree with it or not, it is in the RFC. > Operators may reasonably act on that. > > Yours, > > Joel > On 10/10/2022 9:59 AM, Robert Raszuk wrote: > > > it seems acceptabl

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

; is questionable, the idea that operators might filter it shouldn't be > surprising. > > Thanks > > On Mon, Oct 10, 2022 at 9:24 AM Robert Raszuk wrote: > >> Joel, >> >> Am I wrong understanding that definition of "limited domain" was never &g

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

> that domains using SRH filter it at ingress and egress edges. *it* is a key here. If document says (as I presume Suresh explained) that such ingress filtering will be based on destination address of the packets being the new SRv6 prefix or any other infra address of the AS - all is legal and gr

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

for, and I believe Suresh plans for, is to note that not > using the reserved block complicates the filtering for ingress and > egress. I do not expect this document to discuss what other methods of > filtering could be applied. > > Yours, > > Joel > On 10/10/2022 11

[spring] Fwd: I-D Action: draft-agrawal-spring-srv6-mpls-interworking-10.txt

Hi, It seems that your draft does not cover the most interesting interworking case of SRv6 with MNA enabled MPLS domain. In my view it is therefor incomplete. Do you plan to extend it to discuss/cover such interworking ? Specifically adding SRH embedded actions to MNA actions bidirectionally. M

[spring] Fwd: I-D Action: draft-cheng-spring-srv6-resource-programming-00.txt

Dear WG, This draft is one more attempt to shift SR path selection from ingress node to segment endpoints. Is such direction really something Spring wg endorses ? Functionally all of this type of proposals can be done on ingress nodes making transit nodes lean and carrying less state just using

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Joel, Yes IMO your understanding is correct. That does also mean that anyone who is making assertions that the subject document is introducing per flow "state" is just wrong or simply does not understand SR dogmas. Cheers, Robert. On Sun, Dec 11, 2022 at 12:42 AM Joel Halpern wrote: > Speak

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

Hey Ketan, > The encodings are exactly identical - zero difference (from a quick read). Am I missing something? It looks like RFC9343 is defining extension to IPv6 Options Header while the subject draft is defining an extension to SRH. So while data fields look indeed identical the intended plac

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

te route segments. Hence, I believe > that RFC 9343 already defines what is required to use the Alternate Marking > method in an SRv6 domain. Do you see that I've missed anything? > > Regards, > Greg > > On Fri, Feb 17, 2023 at 8:20 AM Robert Raszuk wrote: > >> He

Re: [spring] Usage of DoH vs SRH TLVs

Hi Joel, > Clearly there are some pieces of information that are closely tied to the SRH IMHO anything that requires some action on the segment endpoints (for example segment by segment performance measurement) is "closely tied to the SRH". Since processing of TLVs is subject to local configurat

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

Andrew, To me the fact that SRv6 is using IPv6 ethertype is a feature not a bug. It allows seamless deployment in any IPv6 enabled network. Yes I personally suggested a new ethertype for SRv6 long time back, but the issue was related to hurdles with IPv6 standards not related to any "security" is

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

t comfortable using it in the absence of this > mechanism. > > > > Thanks > > > > Andrew > > > > > > *From: *Robert Raszuk > *Date: *Wednesday, 29 March 2023 at 10:30 > *To: *Andrew Alston - IETF > *Cc: *adr...@olddog.co.uk , int-a...@ietf.org &

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

Guys, What you are really saying here is that the concept of using network programmability should be killed and we should get stuck for decades to come with closed domains only innovation. I find it quite disturbing especially as we are talking about *Internet* Engineering Task Force produced sta

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

> > Could the SRH be carried directly after the Ethernet header, similar > to how MPLS labels are? > Spot on ! Thank you for this question/point. And if so could you be so kind and elaborate why would it be needed to define anything at all rather than just using SR-MPLS only ? Your suggestion ma

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

9 Mar 2023 at 22:46, Robert Raszuk wrote: > > > > Guys, > > > > What you are really saying here is that the concept of using network > programmability should be killed and we should get stuck for decades to > come with closed domains only innovation. > > &g

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

rt, > > On 30-Mar-23 01:10, Robert Raszuk wrote: > > Nope, that is completely not what I have in mind, > > > > Please remember that transit nodes are not SRv6 aware in closed or open > domain, So my site A (car) can be using SRv6 via any IPv6 transit uplink > > Only if

Re: [spring] [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

Hi Daniele, Could you kindly elaborate on what level of "guaranteed bandwidth" you expect SR to provide ? Especially in the context of _circuit_ emulation ? And even if you build the mechanism to account for bandwidth on a per class of service basis and use controller to push your policies everyw

Re: [spring] [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

mix of admission control and proper planning it is possible to > achieve decent performances. If you want to have a network slice for remote > surgery probably you need something more reliable, but otherwise it's a > good enough solution. > > Cheers, > Daniele > > On Wed

Re: [spring] [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

the guaranteed bandwidth. > > Moreover, pardon me for asking, why intense admission control would be a > problem in the network ? > > Cheers, > Daniele > > On Wed, May 24, 2023 at 4:35 PM Robert Raszuk wrote: > >> > If you want to have a network slice for remote sur

Re: [spring] [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

the TE work around > the IETF. > > Yours, > > Joel > On 5/24/2023 11:59 AM, Robert Raszuk wrote: > > > > why intense admission control would be a problem in the network ? > > Imagine you are Tier 1 and not selling access, but doing basic peering > with other Tier 1s.

Re: [spring] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

Gyan, While I do consider some use cases for what the draft is partially describing what you wrote as justification is really the crux of the matter why IMO this work should not be adopted in SPRING nor any other IETF WG. Namely quote: "IP based optical networks" "IP over optical hop by hop rou

Re: [spring] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

Optical used today for TDM CES (circuit emulation > services) over IP/MPLS, would now also used for Routed Optical SR-MPLS > networks. > > The control plane topic is orthogonal to the draft so don’t think it’s > relevant, however maybe informative references could be added. > > Re

Re: [spring] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

this clarifies the goal of the draft and does address your concerns > > Christian > > On 26.05.2023, at 13:30, Robert Raszuk wrote: > > Gyan, > > If you say that this draft is: " to provide the same circuit switched > 50ms optical bypass available on legacy OTN optical UPSR /

Re: [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Hi Sasha, 1. > Activate multi-topology IGP (e.g., MT-ISIS, RFC 5120 ) Don't you still run default topology which could suffer in the very same - and a very valid issue - you are reporting ? - - - The biggest issue for me for this proposal i

Re: [spring] [EXTERNAL] Re: A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Hi, > I have probably did not say it explicitly, but the default topology would > use its own resources – and experience its own problems, strictly > orthogonal to whatever happens in the dedicated CS topology. > > IMHO and FWIW this could be treated as a possible approach for > implementing the

Re: [spring] [EXTERNAL] Re: A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

> Physical links would be shared, but “soft” resources (queues, buffers > etc.) would not. > Well ingress or egress interface queue is a physical resource last time I checked. Leave alone zero view of intra chassis fabric issues and drops. Then last but not least you are making a huge assumption

Re: [spring] [EXTERNAL] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

gt; that have been associated with the CS topology and its resources (e.g., > steering all non-CS traffic across the default topology), be it > intentionally or due to some transient condition (FRR, micro-loop avoidance > etc.). > > Regards, > Sasha > > *From:* Robert Raszuk

[spring] Your interesting comment

Hi Warren, I have read your justification for Abstain. I have a question to this statement: *"I believe that the document (andSR in general) needs to do a much better job of discussing the security / DoSimplications of what happens when an attacker is able to inject traffic intothe SR domain

Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp

Joel, *Point 1: * Reading RFC8986 I see in section 4.16.2 clear definition of SRv6 running on user hosts. *One of the applications of the USP flavor is when a packet with an SRH is destined to an * *application on hosts with smartNICs ("Smart Network Interface Cards") implementing * *SRv6. The U

Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp

Yours, > > Joel > On 7/14/2023 11:28 AM, Robert Raszuk wrote: > > Joel, > > *Point 1: * > > Reading RFC8986 I see in section 4.16.2 clear definition of SRv6 running > on user hosts. > > *One of the applications of the USP flavor is when a packet with an SRH is >

Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp

, and that they use secure tunnels (not just arbitrary > overlay) between the BRAS then we can as a WG see if that suffices. But > the draft doesn't currently say that. > > Yours, > > Joel > On 7/14/2023 11:40 AM, Robert Raszuk wrote: > > Joel, > > Limited domain (if

Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp

6 uses unsecured tunnels as a means to deliver SRv6 > packets between pieces of the domain, then anyone, almost anywhere in the > Internet, can inject such packets. That is not a limited domain. It is a > wide open domain. > > Yours, > > Joel > On 7/14/2023 12:01 PM, Robert

Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp

t the RFCs do. > Hence, the WG is required to do so. An operator can of course do anything > they want, and they choose their risks. But IETF standardization work is > subject to the restrictions we as a community agree to. > > Yours, > > Joel > On 7/14/2023 12:25 PM,

Re: [spring] Fwd: IETF WG state changed for draft-ietf-spring-srv6-srh-compression

Support. Thx, R. On Mon, Jan 22, 2024 at 3:28 PM Joel Halpern wrote: > (One of the other chairs pointed out that this had not gone to the list. > So forwarding the announcement.) > > This tarts the WG last call on the above document. > > Thank you, > > Joel > > > Forwarded Message

Re: [spring] draft-ietf-spring-srv6-srh-compression

Hi Ron, Is there a problem ? If I read RFC8200 L4 checksum is computed by the packet *originator and validated by the packet's ultimate receiver. * In all SPRING work to the best of my knowledge the vast majority of packets are only encapsulated by transit nodes. Is there any formal mandate in

Re: [spring] draft-ietf-spring-srv6-srh-compression

d. I would be quite fine if > there was explicit text detailing this that was explicitly approved by 6man > as the originators of 8200 (and a clear indication that this document > updates 8200) – or alternatively a -BIS to 8200. Either way – if you break > the checksum – this needs

Re: [spring] draft-ietf-spring-srv6-srh-compression

uggests is too big of a hammer. Instead I see no reason why OAM packets should not contain SRH and resolve the nit that way. On Wed, Feb 7, 2024 at 5:44 AM Mark Smith wrote: > > > On Tue, 6 Feb 2024, 03:17 Robert Raszuk, wrote: > >> Hi Ron, >> >> Is there a problem

Re: [spring] IPR call and Shepherding draft-ietf-spring-srv6-srh-compression

Hi, As contributor I am not aware of any undisclosed IPRs pertaining to this document. Regards, Robert On Thu, Feb 1, 2024 at 5:36 PM Joel Halpern wrote: > 1) This email initiates an IPR call for the subject document. All > authors and contributors, please confirm explicitly to the list that a

Re: [spring] draft-ietf-spring-srv6-srh-compression

Hi, Actually for OAM responses in vast majority of cases vanilla IPv6 packets can be used. Kind regards, R. On Wed, Feb 7, 2024, 10:58 Mark Smith wrote: > > > On Wed, 7 Feb 2024, 20:08 Robert Raszuk, wrote: > >> Hi Mark, >> >> > however UDP and ICMPv6 woul

Re: [spring] draft-ietf-spring-srv6-srh-compression

must use encapsulation that ensures the path > coroutedness for the reflected test packet, e.g., C-SIDs. > > Regards, > Greg > > On Wed, Feb 7, 2024 at 4:14 AM Robert Raszuk wrote: > >> Hi, >> >> Actually for OAM responses in vast majority of cases vanilla

Re: [spring] draft-ietf-spring-srv6-srh-compression

gt; with using C-SID specific to use of a two-way active measurement protocol > like STAMP. > > Regards, > Greg > > On Thu, Feb 8, 2024 at 1:45 PM Robert Raszuk wrote: > >> Greg, >> >> The doubt here is not about test path which truley you are correct to be >

Re: [spring] draft-ietf-spring-srv6-srh-compression

Regards, > Greg > > On Thu, Feb 8, 2024 at 3:45 PM Robert Raszuk wrote: > >> Hi Greg, >> >> Just one nit ... >> >> > that reporting on-path telemetry can be done over the management plane >> >> Just for clarity I did not mean to report on mgmt

Re: [spring] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/

Hi Jeffrey, I have a question here ... Are you completely dismissing the case where monitor itself may be microTAP SR capable or that microTAP capable node may simply IP encapsulate interesting traffic to monitor node which in turn would be just reachable in the IGP and not connected directly to

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

All, It looks like previous discussions on this topic are lost again and we keep starting over and over every few weeks from scratch. It has been established that the checksum issue is moot for 99.9% of this discussion as we are talking about tunneled packets encapsulated with new header. Checksu

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

outer still > receives the packet. Therefore – if we went with zero checksums – by the > letter of 8200 – no UDP packets without an SRH would flow, because 8200 > clearly says that they must be dropped. > > > > Thanks > > > > Andrew > > > > > >

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

> > > > Thanks > > > > Andrew > > > > > > > Internal All Employees > From: Robert Raszuk > *Date: *Monday, 25 March 2024 at 18:23 > *To: *Andrew Alston - IETF > *Cc: *Tom Herbert , Ron Bonica > , spring@ietf.org > *Subject: *Re: [spring] Chair

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Actually looking at this from the perspective where SRH may be omitted I see in the subject draft this clearly stated: A source node steers a packet into an SR Policy. *If the SR Policy results in a Segment List containing a single segment*, and there is no need to add information to the SRH flag

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Hi Tom, I don't think so, but I admit I may not be aware of some interesting use cases Many thx, R. On Mon, Mar 25, 2024 at 5:57 PM Tom Herbert wrote: > On Mon, Mar 25, 2024 at 9:40 AM Robert Raszuk wrote: > > > > > > Actually looking at this from the pe

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

, 2024 at 6:06 PM Tom Herbert wrote: > On Mon, Mar 25, 2024 at 10:04 AM Robert Raszuk wrote: > > > > Hi Tom, > > > > I don't think so, but I admit I may not be aware of some interesting use > cases > > Robert, > > Based on previous discussions, m

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Hi Alvaro, > Given that the issue is constrained to an SR domain The issue seems much more constrained that that. * It seems very clear that there is no issue if we encapsulate packets with new IPv6 header to make it SRv6 * It seems that the issue is also non existent if SRv6 end hosts add an I

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

not rhetorical. Maybe I am missing something, but is there > any real benefit in continuing to bind SRRv6 to IPv6? > >Ron > > Juniper Business Use Only > -- > *From:* Tom Herbert > *Sen

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

f limitations on STD documents or security/operational impact. > Rather, debt incurred in technology tends to accumulate over years > mercilessly. > > --- tony > > On Tue, Mar 26, 2024 at 6:24 PM Robert Raszuk wrote: > >> Ron, >> >> While I did suggest the use

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

rs this > choice though – especially when it would actually help get their stuff > deployed in more networks potentially. > > > > Andrew > > > > > Internal All Employees > From: Tom Herbert > *Date: *Wednesday, 27 March 2024 at 02:52 > *To: *Ron Bonica &

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

mode (without its own ethertype) – or in a > hybrid mode (though when we wrote the raviolli draft we chose not to > discuss the semantics of hybrid operation because of complexity and because > it probably would be a bad idea – but it CAN be done) > > > > Thanks >

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Nick, So which part of RFC7282 ? In tracker I see zero open issues: https://github.com/ietf-wg-spring/draft-ietf-spring-srv6-srh-compression/issues All issues have been addressed. So what is the problem ? Thx, R. On Wed, Mar 27, 2024 at 11:43 AM Nick Hilliard wrote: > Robert Raszuk wr

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

drew > > > > > > > Internal All Employees > From: Robert Raszuk > *Date: *Wednesday, 27 March 2024 at 13:58 > *To: *Nick Hilliard > *Cc: *Andrew Alston - IETF , > spring-cha...@ietf.org , spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] Chair

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Alvaro, On this specific topic I think you have flatted it a bit too much. These are apparently the options on the table: A) Original packet get's encapsulated with IPv6 header A.1 SHR is added to it A.1.1. Regular SIDs are used A.1.2 Compresses SIDs are use

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

if operator who enables SRv6 in the first place sees those checksum errors how difficult is to address it ? Thx, Robert On Thu, Mar 28, 2024 at 3:29 PM Tom Herbert wrote: > On Thu, Mar 28, 2024 at 6:26 AM Robert Raszuk wrote: > > > > Hi Alvaro, > > > > On this specific

Re: [spring] [EXTERNAL] Separating Threads (draft-ietf-spring-srv6-srh-compression)

Hi, At this point of time new ethertype buys us nothing then disturbance. If anything is here to discuss is the question if in the cases of using C-SID/uSID hosts talking native SRv6 and using more then one uSID should also use additional 40 octets of IPv6 extra header or not. It could be option

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

SRv6 there is no issue. Even Andrew agreed with that :) Cheers, Robert On Thu, Mar 28, 2024 at 4:36 PM Tom Herbert wrote: > On Thu, Mar 28, 2024 at 7:46 AM Robert Raszuk wrote: > > > > Hi Tom, > > > > > because of SRH > > > > Ok I buy this that the

Re: [spring] Requiring Tunneling - subject change

ask that if there is more to say, people use this subject line. > > I look forward to comments from folks beyond Tom and Robert on this > subject. > > Yours, > > Joel M. Halpern > On 3/28/2024 11:40 AM, Robert Raszuk wrote: > > Hi Tom, > > Not really. > &

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

Hi Alvaro, Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the > behavior when an originating node inside an SRv6 domain creates a > packet with a C-SID as the final destination. > *This description differs from the text in Section 8.1 of RFC8200.* I would like you to clarify the

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

uSID container is used as the destination address and no SRH > is present, then in addition to the above problem there is no routing > header to trigger the behavior described. > > Yours, > > Joel > On 4/3/2024 4:22 PM, Robert Raszuk wrote: > > Hi Alvaro, > > Secti

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

ification > people want to the text in the compression draft before we send the > question over to 6man. > > Yours, > > Joel > On 4/3/2024 5:15 PM, Robert Raszuk wrote: > > Hi Joel, > > My interpretation of text from RFC8200 is that it allows discrepancy > between

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

t; This is broken – severely broken. > > > > Andrew > > > > > Internal All Employees > From: spring on behalf of Francois Clad < > fclad.i...@gmail.com> > *Date: *Thursday, 4 April 2024 at 14:49 > *To: *Joel Halpern > *Cc: *SPRING WG List , Rob

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Tom, Yes I am with you here. However let's observe that this is pretty common best practice to disable any hardware offload on the box when running tcpdump or wireshark. In fact some implementations (F5) do it for you automagically :) And as it has been said based on the fact that hardware o

  1   2   3   4   5   6   7   >