Thanks Cheng.
I skimmed the Diff and I think you addressed all my point.
Adrian
-Original Message-
From: Cheng Li
Sent: 09 September 2024 18:15
To: spring@ietf.org; bruno.decra...@orange.com; zehua...@foxmail.com;
liu.ya...@zte.com.cn; Joel Halpern
Subject: [spring] Re: I-D Action: draf
se see the latest revison.
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment-09
---
Please decide "P-flag" or "P-bit". Probably flag.
[Cheng]OK, P-flag
---
*
<https://mailarchive.ietf.org/arch/msg/spring/AsRF1-XMAbT3yu3GUbvnnU2dyBk/>
[spring] Som
If any allocation had been made (early or otherwise), I'd see it here
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
and here
https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
right?
A
-Or
Thanks, Ron, for showing some of your typical charity and moderation. I have
just been catching up on the SPRING list (a lot can happen in one day) and when
I got to Antione’s email I was upset enough to start write to the chairs to ask
them to bring some better behaviour back to the conversatio
too generally, while others already have perfect definitions,
that will lead to something similar to this document to bring the good into the
light.
Further comments in line…
From: Greg Mirsky
Sent: 12 January 2024 00:09
To: Carlos Pignataro ; Adrian Farrel
Cc: Ops Area WG ; IETF IPPM
warded message -
From: Carlos Pignataro mailto:cpign...@gmail.com> >
Date: Fri, Jan 5, 2024 at 3:38 PM
Subject: New I-D -> Guidelines for Charactering "OAM"
To: Ops Area WG mailto:ops...@ietf.org> >, Adrian Farrel
mailto:adr...@olddog.co.uk> >
Hi, Ops Area WG,
Ever
issues, in fact, resolved and just listed here for information?
>> If so, then I think it is time to remove the section or add a note that the
>> issues have been resolved. If not, then we need a plan to resolve them!
>
> This text indeed seems outdated. We will work with the
Hey SPRING,
Please be aware of this working group last call in MPLS. Review comments
greatly appreciated and should be sent to the MPLS list.
Last call ends 9th January at 9am GMT
Cheers,
Adrian
-Original Message-
From: mpls On Behalf Of Adrian Farrel
Sent: 18 December 2023 20:47
To
ly to address the issue of “is this one or two solutions presented in a single document?”) to show that you can mix compression flavours in the same SID list. That means that advertising both flavours of C-SID is both possible and acceptable. So you can’t gloss over answering what happens when both flavour
Hey there,
So, it's over a year since Bruno asked this question, and eight months since
the current revision expired.
I don' see anything on the list, and there was no mention in the meeting at
IETF-118.
Can we have a status and plan, please?
It's OK if the authors have decided to give
Hi again Francois,
Thanks for your patience while I got back from Prague.
I have looked through the diffs and respond in line below.
This is good work, and captures very nearly everything. I snipped out every
point of agreement.
Best,
Adrian
>> 0. Please get into the habit of
Hi,
This review is in answer to Joel's request on the mailing list. I come to
this document without a lot of history on SRH compression (although
I had some chats with Cheng Li, which helped me to not embarrass
myself with some of my more stupid questions) and I have deliberately
not read any of
Hey Joel,
I have not been following the SRv6 compression work closely, so I believe I
fill the criteria for the detailed review for clarity and implementability. I'd
be particularly interested in what issues (if any :-) are thrown up by the
effort of clarifying the text.
I can't look at the dr
which will need to start using the new values before shipping. Note
that there is a Private Use part of the registry available for early
implementation and prototyping.
Thanks,
Francois
On 26 Jul 2023 at 10:46:13, Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Hi,
You h
Hi,
You have an impressive Implementation Status section. Well done for
compiling this and keeping it up to date.
I note that a number of IANA assignments are marked as TBA while others have
been assigned from the First Come First Served part of the registry.
This leads me to two things:
1. Cou
Thanks.
Looks like all my comments have been addressed.
Adrian
From: 程伟强
Sent: 27 June 2023 15:08
To: spring ; i-d-announce
Cc: Stewart Bryant ; Adrian Farrel
Subject: Re:[spring] I-D Action: draft-ietf-spring-mpls-path-segment-09.txt
Hi,
We just updated the draft to
[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 good initiative and worth discussion. Thanks
for the draft.
I am particularly reminded of two MPLS-related discussions:
- The first was the introduction of Ethertype 8
Hi all,
I reviewed this document a couple of times as it progressed through the
working group, and my comments were addressed.
Here is an additional, small point. In Section 2 you have:
When Path Segment is not allocated from the SRGB pool, the
intermediate nodes MUST not see the Path Segm
n the material in RFCs.
If we put in text about not retaining it, people later who had not seen
the discussion would find that confusing.
Yours,
Joel
On 10/14/2022 6:27 AM, Adrian Farrel wrote:
> Hi Joel, chairs.
>
> Thanks for working on this.
>
> Can I ask, just for clarific
Hi Joel, chairs.
Thanks for working on this.
Can I ask, just for clarification, what the conclusion is on whether this
section is going to remain in the document when it becomes an RFC. I find the
text a little confusing because it talks about "an I-D [that] is ready for WG
last call", but lat
Thanks, Acee.
The reason you cite may not be perfect, but your advice is. I shall suppress my
urges.
Adrian
4.
A node
taking part in this mechanism accomplishes this by using the ARG part
[RFC8986] of the Destination address field of the IPv6 header to come
up with a new Dest
Thanks for the speedy turn-around, Suresh.
Lots of snipping to just a few open points….
3.
"It is also fairly clear"
Well, that is illuminating :-)
Perhaps you want to make statements about the SID elements and not about
the clarity of the referenced documents?
Sure :-). Suggest
OLD
Hi Jen, all,
I've done a review of this document as part of working group last call.
I found quite a few nits and so on, so I think the document needs some
more work before escaping from the working group and being present for
publication.
Cheers,
Adrian
==
I find it odd that this is an Inf
Hi Joel,
Thanks for bringing this to the WG for discussion.
As one of the authors of RFC 7942 I want to comment on the idea of including
this “snapshot” status at the time of publication within the published RFC. I
think this changes the purpose of collecting the information and making it
Hi,
This is a bit of a "fly-by" review. I happened to need to read the draft
to check on the use of SRH flags, so here are a few quick comments.
I hope they are useful.
Best,
Adrian
==Medium==
General
Some of my points below are cleared up when I finally got to Section 7
and discovered that yo
Hi,
I've been on a roll reading and reviewing network slicing and enhanced
VPN drafts, so I thought I'd get round to this one. A bit surprised to
find it has expired - you probably want to post something to keep it
alive.
Seems most drafts I review these days I end up writing a comments that
goes
Hey Joel,
Stuff happens (TM)
This is OK with me. It is clearly in scope and something that the WG should
be looking at. This draft is a good enough starting point. Let's move on to
work on it.
Cheers,
Adrian
-Original Message-
From: spring On Behalf Of Joel M. Halpern
Sent: 28 Septembe
Szarkowicz
Sent: 27 September 2021 08:10
To: John E Drake
Cc: Lizhenbin ; TEAS WG ; Dongjie (Jimmy)
; spring@ietf.org; m...@ietf.org; 龚立艳
; draft-filsfils-sprin
; draft-ali-teas-sprin
; ext-vishnupa...@gmail.com
; Adrian Farrel ; Tarek Saad
; draft-decraene-mpls-
Subject: Re: [Teas] More
I think that, before jumping in to criticise
draft-dong-spring-sr-for-enhanced-vpn too much for the *potential* for state
explosion, everyone should read draft-ietf-teas-enhanced-vpn and
draft-dong-teas-enhanced-vpn-vtn-scalability with some care (as Pavan appears
to have done :-) to see the di
southbound interface to install
that information in the (management/control parts of the) network nodes.
Cheers,
Adrian
From: Robert Raszuk
Sent: 31 January 2021 00:46
To: Adrian Farrel
Cc: James Guichard ; SPRING WG
; spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft
Thanks, Jim,
I've been following the enhanced VPN work in TEAS and I see it as a key
piece of the network slicing work.
It's time that we had some protocol solutions that serve the VPN framework,
and this is a suitable starting point. I like that it is not specifying
additional protocol wid
Hi again Gyan,
I think we’re narrowing down and getting somewhat esoteric for the mailing
lists we’re spamming.
> Similarly other use cases such as with TEAS TS-Transport slice and being able
> to provision TS and capturing the TS Enhanced VPN RT & resource information
> and leveraging BGP-LS
Hi Gyan,
Sorry, I missed this (got caught on a filter cos it was a bit spammed to a lot
of lists :-).
> I have noticed that after reviewing many drafts across many WGs it seems in
> the
> industry that the lines seem to be blurred between a PCE controller, ODL or
> Openflow SDN Controll
Hi Jim,
I've been working on the Enhanced VPN framework in TEAS and I consider it a
good foundation for providing a more sophisticated VPN service that also
addresses the needs of network slicing.
So I'm pleased to see this work being examined in SPRING. It's been a while
since I read this
Please stop this. It is absolutely no way to conduct yourself on an IETF
mailing list.
While it is true that one of the signatories of the appeal to which you refer
is also an author of draft-bonica-6man-comp-rtg-hdr you should not:
* Write words that imply that all of the authors a
Thanks Pablo and Happy Imminent New Year.
> I have reviewed your suggested changes and incorporated them
> in the latest revision of the document.
Great. I will try to pull that and review it soon.
> Please see below inline for more detail.
[snipped]
>> 4.1
>>
>> I was surpri
Hi Pablo,
Very good progress. Thanks for the work.
I have snipped down to the conversation points below.
The document has gone through a lot of changes in -06 and clearly there is a
-07 in the pipe. I'll wait for that before doing a re-read.
Best,
Adrian
[snip]
>> Another 'normal' thing to d
[Hmmm, there were a lot of people in the to/cc fields. I trimmed a bit because
(hopefully) some of them are subscribed to the mailing lists.]
Brian,
I think some of the notion of "popping an SRH" may be associated with the idea
of having more than one SRH present. Whether that is a good idea is
Hi,
Thanks to the authors for the work on this draft. I've done a review
which is the first time I have looked at the draft for several
revisions. My thoughts are included below.
I think that considerable editorial work is needed before we can claim
that this document is ready for publi
Hi SPRING and document authors,
Now we've adopted this draft, I thought I should give it a more careful
reading. Here are some thoughts and nits.
Best,
Adrian
=== General thoughts ===
I think that the Abstract and Introduction need to make it clear (as the
title does, and does Section 2) that t
inal Message-----
From: spring On Behalf Of Adrian Farrel
Sent: Thursday, May 23, 2019 4:48 AM
To: 'Rajesh M' ; 'Loa Andersson'
Cc: 'SPRING WG' ; i...@ietf.org
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00
Hi all,
I don't think that a loose stateme
Hi all,
I don't think that a loose statement of recommendation is quite enough.
Trivially, the IPv6 header must come first and the upper layer header must come
last.
I think that although the inclusion of the two destination options headers is
optional, their positions are quite tightly constr
Robert,
Coincidence is a mighty thing, but attributing coincidence to planning is the
slippery slope you spoke of.
Drawing conclusions about an “overall strategy” that I might be part of is
potentially offensive. Should I be offended?
Let’s just do the work and stop second guessing a
Robert,
Coincidence is a mighty thing, but attributing coincidence to planning is the
slippery slope you spoke of.
Drawing conclusions about an “overall strategy” that I might be part of is
potentially offensive. Should I be offended?
Let’s just do the work and stop second guessing a
Hey Robert,
Thanks for your response, but I think you are not taking my requests at face
value.
> I think you are on a very slippery slope here :) Hope you are
> double diamond skier !
As it happens. But perhaps that is not wholly relevant.
> With point you are making here you ar
Hi chairs,
I hate to sound like a broken record. I just want to get this issue
clarified before we get to a late stage and risk being forced to start
again.
RFC 8200 defers to RFC 4291 for the definition of an IPv6 address. RFC 4291
has a somewhat simplistic and possibly historic definition
Thanks for this poll, Bruno,
Before taking up work on this draft, would it be worth working with 6man to
check that the repurposing of IPv6 addresses would be unlikely to cause a
great fight? It would probably be better to not have two WGs fighting.
And, in case someone is confused by my co
Bruno, all,
I didn't pay much attention to this work when it first came out, but looking
more closely now, I think there is a useful function described here.
Obviously there is some polish needed, but that's OK at this stage in the
process and doesn't stop adoption.
I support the WG picking this
This draft has been around the block a bit, but certainly needs to progress
because a lot of other things are dependent on it.
Fortunately after plenty of review and updates (thanks to the authors), I
think it is now ready to become an RFC.
Adrian
-Original Message-
From: spring On Beha
On 12/6/18 12:09 PM, Adrian Farrel wrote:
> Hi Bruno,
>
>> Speaking as an individual contributor and co-author:
>> - I think that this is fine to make a difference between an inconsistency
> from
>>a (one) faulty sender, and an inconsistency from two correct sende
rian
--
Fairy tales from North Wales brought to you for Christmas
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Thursday, December 06, 2018 12:35 PM
To:
document
that says how to protect against bugs otherwise the document is
contradicting itself
Thanks again for the thorough review
Ahmed
On 12/3/18 2:28 PM, Adrian Farrel wrote:
Hi all,
Thanks to the authors for the multiple revisions since -17. I reviewed the
Diff.
All of my review comm
Hi all,
Thanks to the authors for the multiple revisions since -17. I reviewed the
Diff.
All of my review comments along the way seem to have been addressed and I
support moving to publication (soon).
One thing, in Section 2.5.
An implementation MUST NOT allow the MCCs belonging
Last item on the agenda...
Multicast Within SR-MPLS A Comparative ReviewIan 20 15:30
A
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 06 November 2018 07:26
To: Stig Venaas; spring@ietf.org
Cc: Zafar Ali (zali)
Subject: Re: [spring] Multicast w
welcome comments.
Thanks,
Adrian
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: 13 October 2018 18:04
> To: Adrian Farrel; John Drake
> Subject: New Version Notification for
> draft-farrel-spring-sr-domain-interconnect-
>
ubject: I-D Action: draft-farrel-spring-sr-domain-interconnect-04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Interconnection of Segment Routing Domains - Problem
> Statement and Solution Lands
nt-routing-m...@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13
Thanks a lot for the through review
I posted version 14 few minutes ago to address your comments
See my reply as #Ahmed
On 5/25/18 2:22 AM, Adrian Farrel wrote:
Hi,
I think it is well past
James,
I believe "iff" was intended as written.
https://en.wikipedia.org/wiki/If_and_only_if
Adrian
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of RFC Errata System
> Sent: 08 June 2018 09:11
> To: sprev...@cisco.com; cfils...@cisco.com; bruno.decra...
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 RFC.
Cheer,
Adrian
>
> From: Loa Andersson
> Sent: 07 June 2018 11:15:03 (UTC+00:00)
Hi,
I think it is well past time that we completed this foundation work
and got an RFC published. So I support passing this draft to the AD
again.
However, we do need to clean it up first. Hopefully this won't be a
lot of effort for the editors as nearly all I found were editorial
nits.
As a
Hi Zafar,
Thank you for the comments. We are not aware that any IPR has been disclosed
in relation to any of the relevant drafts. If there are such IPR issues, we
encourage them to be disclosed in accordance with the IETF policy. In the
meantime, we believe our draft remains appropriate and
ring" when rechartering Spring. Spring needs to recharter now. I didn't
> see any emails on the list which advised against Spring policy routing and the
> related OAM mechanisms as future work items.
>
> Regards,
>
> Ruediger
>
> -Ursprüngliche Nachricht
There *might* be some disconnect between:
- What TEAS means by "TE"
- What TEAS is perceived to mean by "TE"
- What Spring means by "TE"
- What Spring is perceived to mean by "TE"
An option (although it would slow the discussion a bit - it might speed it in
the long term) would be to try to clarif
Yes, OAM, please!
There has been some discussion recently about where new SR-related work should
be done :-)
I wonder whether a task for the WG would be to provide clearer coordination of
the related work in other WGs. Maybe that is a "cookbook", maybe it is just a
WG wiki. But it seems to m
Hi Jim,
(Wonders why Wim and Jim. Anyone called Tim want to comment?)
> 3. Support for SFs that do not handle MPLS
>
> There is, in our opinion no difference between an SF that does not handle
> the
> NSH in RFC 8300 and an SF that does not handle MPLS in this document. Both
> n
d
routers and SFs support NSH?
Cheers,
Adrian
> On 16/03/2018, 22:12, "mpls on behalf of Adrian Farrel"
> on behalf of adr...@olddog.co.uk> wrote:
>
> All,
>
> The authors of draft-farrel-mpls-sfc have listened carefully to the
> reviews and
>
e Wood - A bumper collection of twenty-two new tales
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct at IETF-101
> -Original Message-
> From: Zafar Ali (zali) [mailto:z...@cisco.com]
> Sent: 17 March 2
All,
The authors of draft-farrel-mpls-sfc have listened carefully to the reviews and
comments starting with MPLS-RT reviews, continuing through the debate on various
mailing lists, and including private emails sent to some of us.
We see three points to address:
1. Discussion of Segment Routing
I, too, hope we can move to a technical discussion of the differences between
the proposals and not spend time thrashing around in IETF politics. I'm sure
the ADs will help us understand what is written in the various WG charters, so
our best next step would be to read (you know, like all the wo
___
> From: internet-dra...@ietf.org
> Sent: 18 December 2017 17:25:49 (UTC+00:00) Dublin, Edinburgh, Lisbon, London
> To: John E Drake; Adrian Farrel
> Subject: New Version Notification for
draft-farrel-spring-sr-domain-interconnect-
> 02.txt
>
> A new version of I-D, draft-farre
omments 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 further, offline.
>
> Thanks
>
>
Thanks for helping me break my resolution to leave this thread alone :-(
>>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that
>>> breaks SR
>>> Architecture, highly unscalable and complicated to implement.
>>
>> [JD] Do you have any evidence to justify any of your assertio
Let's unpick a couple of things...
1. This work is not talking about per-flow accounting, it is talking about peer
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the net
ation.
Adrian
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: 03 November 2017 12:42
To: Acee Lindem (acee)
Cc: spring@ietf.org; Adrian Farrel; Shraddha Hegde
Subject: Re: [spring] Slot request for IETF 100
I would suggest that the draft define the augmentation o
; Authors : Stewart Bryant
> Adrian Farrel
> John Drake
> Jeff Tantsura
> Filename: draft-bryant-mpls-unified-ip-sr-03.txt
> Pages : 18
> Date: 2017-
ng Domains - Problem
> Statement and Solution Landscape
> Authors : Adrian Farrel
> John Drake
> Filename: draft-farrel-spring-sr-domain-interconnect-01.txt
> Pages : 33
> Date: 2017-10-29
>
To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-bryant-mpls-unified-ip-sr-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : MPLS Segment Routing in IP Networks
> Authors :
this document?
Thanks,
Adrian
> -Original Message-
> From: rtg-dir [mailto:rtg-dir-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 08 June 2017 18:13
> To: rtg-...@ietf.org
> Cc: rtg-...@ietf.org; spring@ietf.org;
> draft-ietf-spring-ipv6-use-ca...@ietf.org
>
Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 14 August 2017 12:53
> To: 'Xuxiaohu'
> Cc: spring@ietf.org
> Subject: [spring] Author/contributor [Was: New Version Notification for draft-
> bryant-mpls-unified-ip-sr-01.txt]
&g
ugust 2017 20:23
To: Adrian Farrel
Cc: m...@ietf.org; spring@ietf.org
Subject: Re: [mpls] FW: New Version Notification for
draft-bryant-mpls-unified-ip-sr-01.txt
Sorry but forgot one more really useful advantage which your proposal is
lacking ...
D)
In SRv6 when you traverse SR node you mov
Greetings Xiaohu,
> When you submitted the -00 version of this draft with my name being listed in
> the coauthor list but without my permission, I tolerated it so as to give face
to
> you, although it had caused unnecessary confusion in the IETF, especially amon
g
> the coauthors of draft-xu-mpls
Hi Wim,
> The draft only defines procedures for SRoIP E2E, why don’t we envision SRoIP
> to
> Interwork with native MPLS-SR.
:
> You could envision certain segments to do SRoIP and other segments to have
> native MPLS-SR capability.
Yes, the "mixed mode" is both interesting and useful.
In fact,
s.
Thanks,
Adrian
>
> From: internet-dra...@ietf.org
> Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, London
> To: Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version Notification for draft-bryant-mpls-unifie
Reviewer: Adrian Farrel
Review Date: 8th June 2017
IETF LC End Date: 4th May 2017
Intended Status: Informational
Summary:
I have some minor concerns about this document that I think should be resolved
before publication.
Comments:
This document supplies primary use cases for SRv6 in a
Hi,
Just posted
https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/
We think this covers an important hole. The document defines a mechanism using
the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise
the routes to the prefixes in the data center site
85 matches
Mail list logo
