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

Any router that has interfaces of mixed type has to be able to re-write the datalink header. Changing the Ethertype is a trivial part of changing the Mac header and should therefore be considered a fundamental part of the IETF IP forwarding plane.In reading this discussion I am reminded of very

Re: [spring] WGLC for draft-ietf-rtgwg-segment-routing-ti-lfa (01/18/24 - 02/02/24)

This draft is now ready to proceed along the publications path. Best regards Stewart > On 18 Jan 2024, at 23:45, Yingzhen Qu wrote: > > Hi, > > This starts the Working Group Last Call for > draft-ietf-rtgwg-segment-routing-ti-lfa > (draft-ietf-rtgwg-segment-routing-ti-lfa-13 - Topology

Re: [spring] WGLC for draft-ietf-rtgwg-segment-routing-ti-lfa (01/18/24 - 02/02/24)

It is ready for publication.- StewartSent from my iPadOn 18 Jan 2024, at 23:45, Yingzhen Qu wrote:Hi,This starts the Working Group Last Call for draft-ietf-rtgwg-segment-routing-ti-lfa (draft-ietf-rtgwg-segment-routing-ti-lfa-13 - Topology Independent Fast Reroute using Segment Routing). Please

Re: [spring] Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT)

Andrew you assert that explicit null is a significant performance hit. Is that the case? The test for explicit null is skip label if label is zero with no need to look up the label in the main label table (which is very expensive). What do forwarders do here? I had assumed that they special

Re: [spring] Summary of the side meeting on TI-LFA

Just to pick up something that was agreed but was not included in this summary: we agreed to remove the reference to draft-bashandy in order to make the discussion on uloop prevention technology neutral. - Stewart > On 10 Nov 2023, at 09:04, Yingzhen Qu wrote: > > Also sending the email to

Re: [spring] Summary of the side meeting on TI-LFA

Hi Yingzhen, The sounds right Thank you for convening the meeting. Stewart > On 10 Nov 2023, at 09:04, Yingzhen Qu wrote: > > Also sending the email to SPRING WG in case people are interested. > > Hi, > > We had a very productive discussion during the side meeting, and the review >

[spring] Genart last call review of draft-ietf-spring-mpls-path-segment-16

Reviewer: Stewart Bryant Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more

[spring] Mail regarding draft-ietf-spring-mpls-path-segment

Hi, This document has been significantly improved since I reviewed version -08 I do have a few comments on this version that I think could be usefully considered before publication. Best regards Stewart -- 3.1. Path Segment for Performance Measurement As defined in [RFC7799],

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

I agree with Adrian’s comments. This is a good initiative particularly if enhanced as Adrian proposes. Stewart > On 28 Mar 2023, at 03:24, Adrian Farrel wrote: > > [Spring cc’ed because, well, you know, SR. I wonder whether 6man and 6ops > should care as well.] > > tl;dr > I think this is

[spring] Genart last call review of draft-ietf-spring-mpls-path-segment-08

Reviewer: Stewart Bryant Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more

Re: [spring] Martini Pseudowires and SR

Including the PALS and MPLS WGs in the discussion. In the case of PWs, LDP runs directly between the T-PEs to provide the control plane. If it is known that the only use of LDP is to support PW, then a lightweight profile of LDP might be implemented, ignoring unused parts, but this does not

[spring] Rtgdir last call review of draft-ietf-spring-nsh-sr-11

Reviewer: Stewart Bryant Review result: Ready This is a well written document that is ready for publication. There is one point that the IESG should ponder. The authors have asked for a IP type assignment. This is a limited registry that needs to last the lifetime of the IP protocol suite. NSH

Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

g) MPLS label as path segment has an advantage > of using existing implementations for RX packet count. > > Thanks, > Rakesh > > > > > > > > On Thu, Jul 22, 2021 at 10:06 AM Stewart Bryant <mailto:stewart.bry...@gmail.com>> wrote: > Once you

Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

; > <9ae3e214c17d49ed935d87c674ba3ee2.jpg> > <24242e5637af428891c4db731e7765ad.jpg> > E: gregory.mir...@ztetx.com <mailto:gregory.mir...@ztetx.com> > www.zte.com.cn <http://www.zte.com.cn/> > Original Mail > Sender: StewartBryant > To: James Guichard;

Re: [spring] Discussion about SRv6 Midpoint Protection Mechanism Compliance with RFC8200

Presumably the path is N1->N2->N3->N4 with N3 being node protected 3. SRv6 Midpoint Protection Example The topology in Figure 1 illustrates an example of network topology with SRv6 enabled on each node. Chen, et al.Expires January 13, 2022[Page 3]

Re: [spring] draft-hu-spring-segment-routing-proxy-forwarding-14: Post convergence path

+1 S > On 26 Jul 2021, at 21:26, Peter Psenak > wrote: > > Hi Shraddha, > > On 26/07/2021 22:16, Shraddha Hegde wrote: >> WG, >> Regarding Peter’s comment on the mic that TI-LFA can divert from post >> convergence path when SRLG is used for computation I would like to clarify > >> that

Re: [spring] SRv6 compression

> On 26 Jul 2021, at 21:19, Chengli (Cheng Li) wrote: > > For sure, our goal is not to deprecate SRv6 but solving the overhead issue of > SRv6 so that we can use it better. RFC 8663 gives compact packets over an IPv6 network. - Stewart___ spring

Re: [spring] draft-hu-spring-segment-routing-proxy-forwarding-14: Post convergence path

Isn’t the point about TI-LFA that it re-routes on the post convergence path to avoid micro-loops. When you overestimate the failure to provide node protection even though the failure was not a node failure, the repair path may not be congruent with the post convergence path in which case you

Re: [spring] SRv6 compression

> On 26 Jul 2021, at 20:56, Tony Li wrote: > > As I noted within the WG meeting, my preference is that we deprecate SRv6. +1 It is getting out of hand, and is not a good transport network solution. Stewart ___ spring mailing list spring@ietf.org

[spring] Re draft-hu-spring-segment-routing-proxy-forwarding-14

Regarding draft-hu-spring-segment-routing-proxy-forwarding-14 Do you need to provide any protocol to address this case? In the diagram provided, if N1 acts as an anycast SID for N but at high cost, then normal FRR node protection addresses the requirement of delivering the packet to N1 which

Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Once you find yourself needing to include path identifiers in an SR packet, I begin to wonder whether the segment routing design has gone off track. In MPLS we have the ability in both PCE and RSVP to lay out end to end paths in such a way that the forwarding label is the path identifier. If

[spring] Meetecho abrupt termination of meeting

Is it really necessary for Meetecho to abruptly, and without prior que, terminate at the end of the scheduled time? This is not a behaviour in real meetings nor with “normal” telemeeting services. In SPRING the last speaker was cut off mid sentence. I do not find this an acceptable tool for us

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

As an author I think this is a useful text to publish in support of this work that continues in TEAS. I hope that the WG is able to accept it as a SPRING WG draft. Stewart > On 15 Jul 2020, at 12:16, James Guichard > wrote: > > Dear WG: > > This email begins a 2 week WG adoption call for

Re: [spring] Resignation request

> On 2 Mar 2020, at 21:43, Sander Steffann wrote: > > Hi, > >> I have no information about the situation but I do not understand why an AD >> would be declaring consensus in any case - >> that is normally the responsibility of WG chairs. see RFC 2418 section 3.3 > > The only

Re: [spring] SR-MPLS over IPv6？

, September 25, 2019 3:41 PM *To:* Jeff Tantsura ; Ron Bonica ; Chengli (Cheng Li) ; Stewart Bryant *Cc:* SPRING WG List ; SING Team *Subject:* RE: [spring] SR-MPLS over IPv6？ Hi Ron, Similarly I would refrain from using the SR acronym since a key characteristic of the SR architecture

Re: [spring] SR-MPLS over IPv6？

). Cheers, Dan B On 2019-09-25, 8:43 AM, "Jeff Tantsura" <mailto:jefftant.i...@gmail.com>> wrote: Agree with Stuart. SRinUDP is a well defined solution, let’s not mix things. Cheers, Jeff On Sep 25, 2019, 2:39 PM +0200, Stewart Bryant , wrote:     I agree.     Inclusi

Re: [spring] SR-MPLS over IPv6？

I agree. Inclusion of the term MPLS would cause confusion with draft-ietf-mpls-sr-over-ip, which is entitled SR-MPLS over IP. The design decribed in draft-ietf-mpls-sr-over-ip works over both IPv4 and IPv6. Also course, as Ron states, such a name is not a true refelction of the design. -

Re: [spring] “SRV6+” complexity in forwarding

On 20/09/2019 09:44, Robert Raszuk wrote: TI - stands for Topology Independent ... all other LFA modes rely on topologies to be able to compute or not the backup path. Well so does TI-LFA. At some level you have to know the topology to calculate *any* path in SR, else how do you know what

Re: [spring] IPR Poll: draft-xuclad-spring-sr-service-programming

I have no idea whether or not there is any undisclosed IPR on this draft. Please change my affiliation from Huawei to Futurewei Technologies. - Stewart On 28/06/2019 08:20, Francois Clad (fclad) wrote: I am not aware of any undisclosed IPR related to this draft. Thanks, Francois *From:

Re: [spring] Beyond SRv6.

Zafar Please can you clarify: Is that all forwarding ASICs on all platforms or are there some restrictions? - Stewart On 16/09/2019 16:59, Zafar Ali (zali) wrote: Dear Chairs and the WG, As asked by the chairs ... Cisco ASIC is capable of reading and writing an SRH of up to 9 (nine)

Re: [spring] SRv6 Network Programming: ENH = 59

On 09/05/2019 10:12, Ole Troan wrote: On 9 May 2019, at 11:05, Stewart Bryant wrote: On 08/05/2019 19:13, Ole Troan wrote: Ron, Folks, Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 define a set of SIDs that have the following things in common

Re: [spring] SRv6 Network Programming: ENH = 59

On 08/05/2019 19:34, Sander Steffann wrote: The whole point of these identifies is to tell the reader what the meaning is of what follows. Using value 59 like this looks like "when we say 'no-next-header' we actually mean 'ethernet' (probably)". That's just bad engineering, and reminds me

Re: [spring] SRv6 Network Programming: ENH = 59

I agree that implicit payload identity is a bad idea. If the payload is Ethernet, then the IANA Protocol Number Registry suggests that 22 is allocated for that purpose: 22 XNS-IDP XEROX NS IDP ["The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specification",

Re: [spring] draft-gandhi-spring-rfc6374-srpm-mpls return path

-spring-rfc6374-srpm-udp-00#section-3.2.3.1 Hope this answers your question. Thanks, Rakesh On 2019-02-14, 9:43 AM, "spring on behalf of Stewart Bryant" wrote: I am not quite sure what it means to do a two way path measurement in MPLS SR since MPLS SR defines a

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

I have just read the draft and agree that it should be adopted by the WG. It solves an important problem in instrumenting and protecting an SR path. It should be noted that we needed to do something very similar in mainstream MPLS via the synonymous label work which is already adopted.

Re: [spring] Updating the SPRING WG Charter

distribution. Regards, R. On Tue, Jun 19, 2018 at 3:36 PM, Stewart Bryant mailto:stewart.bry...@gmail.com>> wrote: For clarification: Can I assume that we are talking about replication at ingress to a series of  unicast SR paths each to an installed multicast tree

Re: [spring] Updating the SPRING WG Charter

overprovisioning model to eliminate per path state will not work for multicast. Cheers Dave *From:*spring *On Behalf Of *Alexander Vainshtein *Sent:* Tuesday, June 19, 2018 6:38 AM *To:* bruno.decra...@orange.com; Stewart Bryant *Cc:* SPRING WG List ; Rob Shakir *Subject:* Re: [spring] Updating

Re: [spring] Updating the SPRING WG Charter

On 19/06/2018 13:38, bruno.decra...@orange.com wrote: Hi Stewart, Speaking as individual contributor, please see inline [Bruno] *From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Stewart Bryant *Sent:* Tuesday, June 19, 2018 1:19 PM On 01/06/2018 17:05, Rob Shakir wrote

Re: [spring] Updating the SPRING WG Charter

For clarification: Can I assume that we are talking about replication at ingress to a series of  unicast SR paths each to an installed multicast tree close to egress? - Stewart On 10/06/2018 10:58, Robert Raszuk wrote: Hey Sasha, 100% agree with your last post. Very glad to see your

Re: [spring] Updating the SPRING WG Charter

On 01/06/2018 17:05, Rob Shakir wrote: The SPRING WG defines procedures that allow a node to steer a packet through an SR Policy instantiated as an ordered list of instructions called segments and without the need for per-path state information to be held at transit nodes. I am not sure

Re: [spring] Is TI-LFA compatible with the default SR algorithm?

On 14/06/2018 13:45, Alexander Vainshtein wrote: Please note that RFC 5286 explicitly states that it is only applicable to intra-domain routing only with OSPF or IS-IS as IGP. It does not mention the possibility of local policies overriding shortest path routing provided by these

Re: [spring] Is TI-LFA compatible with the default SR algorithm?

that confirms this suspicion.)” ? Thanks, *From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Alexander Vainshtein *Sent:* Wednesday, June 13, 2018 17:00 *To:* draft-bashandy-rtgwg-segment-routing-ti-lfa.auth...@ietf.org *Cc:* Stewart Bryant; Michael Gorokhovsky; draft-ietf-spring-segment

Re: [spring] draft-xu-mpls-sr-over-ip

I have nothing to add beyond what Adrian says. I know of no other IPR. Stewart On 07/06/2018 12:17, Adrian Farrel wrote: Thanks Loa, I don't know of any IPR directly relevant to this draft. I note that this document has a heavy dependency on RFC 7510 and there is IPR disclosed against that

Re: [spring] [mpls] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

barn door after the horse has bolted. Yours Irrespectively, John *From:*spring <spring-boun...@ietf.org> *On Behalf Of *Eric Gray *Sent:* Wednesday, May 2, 2018 10:28 AM *To:* Stewart Bryant <stewart.bry...@gmail.com>; Andrew G. Malis <agma...@gmail.com>; Loa Andersso

Re: [spring] [mpls] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

Be careful. There is text in the draft that talks about ECMP behaviour in different parts of the path, which implies an expectation that the EL is the sole source of entropy. If we make this ST then we will be implicitly standardizing that behaviour. Now as it happens, I thing we need to

[spring] Genart telechat review of draft-ietf-spring-ipv6-use-cases-11

Reviewer: Stewart Bryant Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Comments inline: On 20/11/2017 23:36, Zafar Ali (zali) wrote: Hi Adrian, Some comments are provided in-line. Please note that, we all want to let this lingering tread die and follow-up on the next steps noted during this email exchange. I will be happy to have a webEx call and discuss it

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

any P-router can support this. Stewart On 17/11/2017 03:17, Mach Chen wrote: Hi Stewart, Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the requirements that I heard are from MPLS-SR. Best regards, Mach *From:*Stewart Bryant [mailto:stewart.bry...@gmail.com] *Sent

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

v 17, 2017 04:18, "Mach Chen" <mach.c...@huawei.com> wrote: >> Hi Stewart, >> >> >> >> Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the >> requirements that I heard are from MPLS-SR. >> >> >&

Re: [spring] [mpls] Fwd: Re: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

data on the max label depth such channel may be hidden under yet still visible to forwarding hardware ? Thx R. On Nov 17, 2017 03:49, "Stewart Bryant" <stewart.bry...@gmail.com <mailto:stewart.bry...@gmail.com>> wrote: Resenting with fewer names recipients S

[spring] Fwd: Re: [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Resenting with fewer names recipients S Forwarded Message Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths Date: Fri, 17 Nov 2017 02:45:18 + From: Stewart Bryant <stewart.bry...@gmail.com> To: Mac

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Zafar I don’t think you can assert that fails to comply with the SR arch. There is nothing they are doing that cannot be captured in Netflix/IPFIX and SR needs to work with IPFIX. Stewart > On 16 Nov 2017, at 2:23 am, Zafar Ali (zali) wrote: > > Hi, > > This draft breaks

[spring] Rtgdir early review of draft-bashandy-rtgwg-segment-routing-uloop-00

Reviewer: Stewart Bryant Review result: Has Issues I have been asked to perform an early review of this document on behalf of the Routing Directorate. Summary: A document on this subject is something that the WG should publish, but I think that there are number of issues that the WG need

Re: [spring] Genart last call review of draft-ietf-spring-ipv6-use-cases-10

On 05/05/2017 11:17, Robert Raszuk wrote: And to add one observation .. Stewart makes a point that SR-MPLS can be deployed without mpls control plane. Well it sure does not require LDP however IGP or BGP extensions for SR-MPLS signalling is also an example of mpls control plane ... even

Re: [spring] Genart last call review of draft-ietf-spring-ipv6-use-cases-10

On 04/05/2017 21:20, Alvaro Retana (aretana) wrote: On 5/2/17, 12:57 PM, "Stewart Bryant" <stewart.bry...@gmail.com> wrote: Stewart: Hi! How are you? Thanks for the detailed review! A significant part of the justification seems to evolve around the inability of MPLS to fun

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

Here are a number of WGLC comments on this document. - Stewart Segment Routing with MPLS data plane draft-ietf-spring-segment-routing-mpls-06 Abstract Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through a

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

I agree. Whilst, as indicated later in the thread, some of the cases studied so far may only need a single label, this is a powerful general purpose technology that will be used for many purposes that have not yet been considered. Some discussion of the implication of the label stack limit

Re: [spring] Conflict resolution - a plea for simplicity

)introduce the simplicity of the original proposal (or at least try to improve simplicity in the current scheme). OK, look forward to seeing it. - S Thanks. s. On Dec 2, 2016, at 6:54 PM, Stewart Bryant <stewart.bry...@gmail.com> wrote: There was some discussion on the conflict reso

Re: [spring] WG LC for draft-ietf-spring-segment-routing

On 30/11/2016 10:38, Stefano Previdi (sprevidi) wrote: On Nov 29, 2016, at 8:21 PM, Stewart Bryant <stewart.bry...@gmail.com> wrote: The following are my comments on this text in response to the WGLC. A lot of comments are embedded in the draft text below. However I have some

Re: [spring] draft-ginsberg-spring-conflict-resolution

:26 *To:* LITKOWSKI Stephane SCE/OINIS *Cc:* Stewart Bryant; Les Ginsberg (ginsberg); spring@ietf.org; DECRAENE Bruno IMT/OLN *Subject:* Re: [spring] draft-ginsberg-spring-conflict-resolution Stephane, IP addresses are not used in path computation. Those are just leaves. You can easily compute

Re: [spring] draft-ginsberg-spring-conflict-resolution

> On 8 Jan 2016, at 09:39, > wrote: > > [SLI] Anycast SID is not a conflict because the IP prefix is the same. Taking a long term view why conflate anycast SID with an IP address? SIDs are instructions not addresses, and we may

Re: [spring] Comments on Section 2.4//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

On 10/04/2014 23:38, Robert Raszuk wrote: Please observed that some government networks and obligated by law to run only IPv6. That remark reminds be of the government directive that all departments would run the Government OSI Protocol and communications with government would use same.