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 nec
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 a
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], p
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
> comment
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 SP
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 case
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 e
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 In
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 pub
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.
Stew
> 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 wish to use them to instruct well known
operation in the netwo
: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
https://www.google.com/patents/US9049233
may be applicable, as may some of the cited patents.
Stewart
On 09/09/2016 12:57, Martin Vigoureux wrote:
Authors and Contributors,
it seems that we are missing answers to the IPR question from a good
number of people:
Authors: Clarence, Ahmed, Mar
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 major overarching comments. Although this is called
an architecture it seems to be rather more of a description of how
a large number of other documents
On 30/11/2016 10:38, Stefano Previdi (sprevidi) wrote:
On Nov 29, 2016, at 8:21 PM, Stewart Bryant 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 major overarching comments. Although this
There was some discussion on the conflict resolution draft at IETF97
that got cut off with a request to discuss on the list.
As I understand the situation, we have a misconfiguration in the network,
and we are being encouraged to take an essentially aggressive strategy
of picking one of the confi
)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 wrote:
There was some discussion on the conflict resolution draft at IETF97
that got cut
> 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 active/avail
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
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
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 you
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 w
> 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
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 n
> 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 ma
+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 an
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]
Internet-Draf
>
> <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 Gu
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
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
i
Stefano,
This is the document that someone interested in SR from and an MPLS
perspective may well start with. A discussion on the issue of label
stack depth and the practical constrains is thus very much in scope. The
fact that you had a debate in the past immediately points to the need
for a
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 controlled
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
On 04/05/2017 21:20, Alvaro Retana (aretana) wrote:
On 5/2/17, 12:57 PM, "Stewart Bryant" 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 function in an IPv6 only network.
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
i
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 to
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 the SR architect
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
To: Mach Chen , stephane.litkow...@orange.com
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" <mailto:stewart.bry...@gmail.com>> wrote:
Resenting with fewer names recipients
S
Forwarded Message -
I would like to ask a fundamental question here.
Do we need transit counters for only MPLS-SR, or do we need it for
MPLS-LDP as well?
If we need it for both, then we need to have this discussion in a
general MPLS context and not in an MPLS-SR specific context.
At least some of the methods
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
2017 04:18, "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
>&
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 fu
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
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
upda
barn
door after the horse has bolted.
Yours Irrespectively,
John
*From:*spring *On Behalf Of *Eric Gray
*Sent:* Wednesday, May 2, 2018 10:28 AM
*To:* Stewart Bryant ; Andrew G. Malis
; Loa Andersson
*Cc:* m...@ietf.org; spring@ietf.org; mpls-...@ietf.org;
draft-ietf-mpls-spring-entrop
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 R
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
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 protocols
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 whe
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 suppo
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
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 the
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
cl
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.
Howeve
I am not quite sure what it means to do a two way path measurement in
MPLS SR since MPLS SR defines a per packet unidirectional path. However,
assuming that this makes sense, I don't see how the return path
information is carried in the RFC6374 message. The draft does not ask
IANA for any ne
-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
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", AA-
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:
- they are consumed by the egress node (SL == 0)
- they tell the egress node how to forward the pay
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 o
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:
- they
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)
“128
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: *Ro
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
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.
- St
).
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
, 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 as
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
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
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
70 matches
Mail list logo