Reviewer: Joel Halpern
Review result: Has Nits
This is a rtg-dir requested review.
Summary: Ready for publication as an Informational RFC with some minor items
that should be considered.
Major: N/A
Minor:
The introduction treats having a single centralized monitoring system as an
Reviewer: Joel Halpern
Review result: Ready with Issues
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
Reviewer: Joel Halpern
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 wait for direction from your
document shepherd or AD before posting a new version
(resending, +spring as requested)
Thank you for the responses. I will respond in line, marked
. I fear it will shortly get too deep, but the context is
important.
I will rephrase here an issue from another thread that I ahve not seen
your comments on. If Node 9 is sending traffic to Node
I am not aware of any undisclosed IPR relevant to this document.
Thank you,
Joel
From: Rob Shakir
Sent: Thursday, June 27, 2019 2:14 AM
To: draft-guichard-spring-nsh...@ietf.org; SPRING WG List
Subject: IPR Poll: draft-guichard-spring-nsh-sr
Hi Authors, SPRING WG,
In parallel to the call for w
Having gotten various volunteers, and considered what the WG needs, the
SPRING chairs have selected the design team for clarifying the SR over
IPv6 compression situation.
The Design team will be
Co-Chaired by:
Cheng Weiqiang of China Telecom and
Sanders Steffann of SJM Steffann Consulta
Sorry folks. This is the wrong version. I will resend in a moment.
The important error is that it has the wrong affiliation for Cheng
Weiqiang, for which I sincerely apologize.
Yours,
Joel
On 7/7/2020 12:20 PM, Joel Halpern wrote:
Having gotten various volunteers, and considered what the WG
Having gotten various volunteers, and considered what the WG needs, the
SPRING chairs have selected the design team for clarifying the SR over
IPv6 compression situation.
The Design team will be
Co-Chaired by:
Cheng Weiqiang of China Mobile and
Sanders Steffann of SJM Steffann Consultan
My thanks to the authors. The revisions captured here address my
concerns regarding the call for adoption.
Yours,
Joel
On 7/10/2020 3:43 PM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source
Forwarding for your information as requested by the nomcom chair.
Thank you,
Joel
Forwarded Message
Subject: Encourage people to visit NomCom during office hours
Date: Sat, 25 Jul 2020 20:16:18 +
From: STARK, BARBARA H
To: 'Working Group Chairs'
Hi WG Chairs,
Could you le
which
this NomCom is responsible, follows:
LLC Board
- Maja Andjelkovic
IETF Trust
- Joel Halpern
IAB
- Jari Arkko
- Jeff Tantsura
- Mark Nottingham *
- Stephen Farrell
- Wes Hardaker
- Zhenbin Li
IESG
- Alissa Cooper, IETF Chair/GEN AD *
- Alvaro Retana, RTG AD
- Deborah Brungard, RTG AD
-
onsidered MUST have provided acceptance and a
questionnaire response.
LLC Board (3-year term)
Maja Andjelkovic
IETF Trust (3-year term)
Joel Halpern
IAB (2-year term)
Jari Arkko
Jeff Tantsura
Mark Nottingham *
Stephen Farrell
Wes Hardaker
Please provide input to the nomcom.
Thank you,
Joel
Forwarded Message
Subject: NomCom is Open for Community Feedback
Date: Thu, 15 Oct 2020 15:28:59 -0700
From: NomCom Chair 2020
To: IETF Announcement List
CC: i...@ietf.org
Hi IETF,
Your friendly NomCom is currently accepti
Thank you to everyone who has replied to our request for WG feedback. As
soon as the chairs have had a chance to consult, we will let you know
what the next steps are.
Yours
Joel, Jim, and Bruno
On 8/4/2021 2:52 PM, Joel M. Halpern wrote:
The SPRING Working Group Chairs thank the design team f
If you are eligible (or even think you might be, they can sort it out)
please volunteer for the nomcom. The IETF is better if a wider range of
folks help select the leadership.
Yours,
Joel
Forwarded Message
Subject:Full list of volunteers so far
Date: Fri, 15
Looking at this draft, I believe it is mostly editorial. I think I saw
one fix that was technical (and likely necessary), and one
clarification. It would be good to have an email on the list calling
out those items (and any other substantive changes I missed) since this
is a WG document.
Th
I see that one person (thank you) has submitted slides for the meeting.
It would be helpful if all presenters could upload slides at:
https://datatracker.ietf.org/meeting/114/session/spring
Yours,
Joel
___
spring mailing list
spring@ietf.org
https:
Note that the segment routing for enhanced detnet was uploaded as ppt.
We can not share ppt. If I see the pdf in my email in time I will share
it. If not, we will skip that presentation.
Yours,
Joel
___
spring mailing list
spring@ietf.org
https:/
As a reminder (it is not as easy to find as I would like, and will
likely change when the move the ietf to wiki.js) the list of requests
can be found at https://trac.ietf.org/trac/spring/wiki.
Yours,
Joel
On 7/27/2022 4:10 PM, Rishabh Parekh wrote:
Joel,
Maybe you missed my earlier email to
SPRING WG:
At the suggestion of our AD, the WG Chairs have been discussing whether
it would be helpful to be more explicit, in I-Ds and RFCs we produce,
about the announced implementations and known interoperability tests
that have occurred. If the WG agrees, we would like to institute and
p
mentation exist v/s applicable.
Thanks!
Dhruv
On Wed, Aug 3, 2022 at 8:14 PM Joel Halpern wrote:
SPRING WG:
At the suggestion of our AD, the WG Chairs have been discussing
whether it would be helpful to be more explicit, in I-Ds and RFCs
we produce, about the announced implem
posed wording is clear enough about the
information being a snapshot in time, please suggest further wording.
Again, written w/o any hat and hoping to help a useful discussion
Regards
-éric
*From: *spring on behalf of Joel Halpern
*Date: *Wednesday, 3 August 2022 at 16:56
*To: *SPRING WG
The proposal is to document what we can determine. It is NOT to block
publication until it is all implemented.
Yours,
Joel
On 8/12/2022 5:40 PM, Acee Lindem (acee) wrote:
I agree – it’s great to document the implementations but let’s not
require every line of the drafts to implemented prio
With regard to point 1 about MUSTs and implementations, we chose this
because we recognize the reality that what people say is an
implementation of an RFC may not include all the MUST clauses. If we
were protocol police, that would be a problem. In this case, we would
rather know about partia
much higher then spec can handle
.. especially after freezing it after publication.
Thx,
R.
On Sat, Aug 13, 2022 at 12:02 AM Joel Halpern wrote:
With regard to point 1 about MUSTs and implementations, we chose
this because we recognize the reality that what people say
munity benefits.
Cheers,
Jeff
*From: *Joel Halpern <mailto:j...@joelhalpern.com>
*Sent: *Wednesday, August 3, 2022 7:45 AM
*To: *SPRING WG List <mailto:spring@ietf.org>
*Subject: *[spring] Proposed policy on reporting implementation
and interoperabil
:15 PM Joel Halpern wrote:
SPRING WG:
At the suggestion of our AD, the WG Chairs have been discussing
whether it would be helpful to be more explicit, in I-Ds and RFCs
we produce, about the announced implementations and known
interoperability tests that have occurred.
KT
While what you propose may be cleaner, what Ketan asked about is a
common practice. 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 sa
continuing to record implementation status
after publication if there is WG consensus.
Thanks,
Adrian
From: spring On Behalf Of Joel Halpern
Sent: 03 August 2022 15:45
To: SPRING WG List
Subject: [spring] Proposed policy on reporting implementation and
interoperability
SPRING WG:
At the
As the IETF is moving its tools from trac to newer wiki tooling, the WG
chairs have worked with staff (Greg Wood did most of the work) to move
the SPRING wiki to the new tools.
You can now find the SPRING wiki at: https://wiki.ietf.org/group/spring
(The old wiki at https://trac.ietf.org/trac/s
For your information. Nominating people you consider well-qualified is
one good way to help the IETF process. Once nominations are completed,
providing feeedback on niminees will be another good way to help the
process.
Thank you,
Joel
Forwarded Message
Subject:
Below is an email Jen sent as co-chair of 6man, asking specifically for
SPRING input on some questions. Please comment on the questions asked
below.
Yours,
Joel
--
Hello,
This email starts the 6man Working Group Last Call for the "Segment
Identifiers in SRv6" draft
(https://datatracke
Hmmm. I read "signal" in the draft as "indicate". That is, for
example, if there is an address range defined to be reserved for SIDs
then that range appearing in the destination address is the "signal".
Yours,
Joel
On 10/1/2022 12:09 AM, Fred Baker wrote:
It talks about a signal, but the s
I wonder if we could / should add a sentence or two related to the
address block noting that if an operator chooses to use other address
blocks for the SRv6 SIDs then they need to be extra careful about
configuring their edge filters to prevent leaks inwards or outwards?
Yours,
Joel
On 10/6/
0/7/2022 9:04 PM, Suresh Krishnan wrote:
Hi Joel,
Thanks for your comment. Please find response inline
On Oct 6, 2022, at 11:15 PM, Joel Halpern wrote:
I wonder if we could / should add a sentence or two related to the
address block noting that if an operator chooses to use other address
bloc
Thanks. Good enough for me.
On 10/7/2022 9:16 PM, Suresh Krishnan wrote:
Hi Joel,
On Oct 7, 2022, at 9:07 PM, Joel Halpern wrote:
Almost, but not quite. The first part, up to "egress points" is
fine. But the description of the reasons leaves out one case I think
is importa
Robert, I am having trouble understanding your email.
1) A Domain would only filter the allocated SIDs plus what it chooses to
use for SRv6.
2) Whatever it a domain filters should be irrelevant to any other
domain, since by definition SRv6 is for use only within a limited
domain. So as far
more
encap.
If there is any spec which mandates that someone will drop my IPv6
packets only because they contain SRH in the IPv6 header I consider
this an evil and unjustified action.
Kind regards,
Robert
On Sat, Oct 8, 2022 at 7:40 PM Joel Halpern wrote:
Robert, I am having trouble un
IPv6 packets only because they contain SRH in the IPv6 header I
consider this an evil and unjustified action.
>
> Kind regards,
> Robert
>
> On Sat, Oct 8, 2022 at 7:40 PM Joel Halpern mailto:j...@joelhalpern.com>> wrote:
>
> Rober
R.
On Sun, Oct 9, 2022 at 4:37 PM Joel Halpern wrote:
We require, per the RFC, blocking SRH outside of the limited
domain for many reasons.
One example is that it turns SRH into a powerful attack vector,
given that source address spoofing means there is little way to
: *ipv6 on behalf of Joel Halpern
*Date: *Sunday, 9 October 2022 at 16:38
*To: *Robert Raszuk
*Cc: *6man , SPRING WG List
*Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
We require, per the RFC, blocking SRH outside of the limited domain
for many reasons.
One example is that it turns
h's I-D.
Regards
-éric
*From: *Joel Halpern
*Date: *Monday, 10 October 2022 at 15:36
*To: *Eric Vyncke , Robert Raszuk
*Cc: *6man , SPRING WG List
*Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
Eric, you seem to be objecting to something I did not say. I have not
asked, and d
ated to Suresh's I-D.
Regards
-éric
*From: *Joel Halpern
*Date: *Monday, 10 October 2022 at 15:36
*To: *Eric Vyncke , Robert Raszuk
*Cc: *6man , SPRING WG List
*Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
Eric, you seem to be objecting to some
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 Halpern
wrote:
Protection from leaking inwards is required by the RFCs as far as
The WG call for this policy completed. The WG chairs reviewed the
comments, and modified the policy accordingly. Below is the new text
which applies from here on. This will get posted in a suitable place on
the WG wiki.
--
For this working group, when an I-Ds is ready for WG last call
relevant question for this draft.
Yours,
Joel
On 10/10/2022 10:31 AM, Ole Troan wrote:
Joel,
On 10 Oct 2022, at 15:36, Joel Halpern wrote:
Eric, you seem to be objecting to something I did not say. I have not asked,
and do not expect, for the document to mandate or even suggest that arbitrary
gal and great.
But you keep stating that filtering can also happen based on presence
of SRH alone - irrespective of the destination address of the packet.
That is something I have hard time to agree with.
Best,
R.
On Mon, Oct 10, 2022 at 5:35 PM Joel Halpern wrote:
There appear to be
Am I wrong understanding that definition of
"limited domain" was never approved by any formal IETF process ?
>
> If so do you really think we should be bounded
on something which has been defined outside of IETF ?
>
>
For your information, the Routing ADs have announced the below policy
and recommendations.
Yours,
Joel
Forwarded Message
Subject:Directorate Early Reviews
Date: Wed, 12 Oct 2022 07:29:38 +
From: Andrew Alston - IETF
To: rtg
the draft / RFC" a couple of times.
Could you clarify, and if necessary tweak the wiki text.
Many thanks.
Adrian
-Original Message-
From: spring On Behalf Of Joel Halpern
Sent: 10 October 2022 15:18
To: SPRING WG List
Subject: [spring] SPRING WG Implementation Information Policy
al Message-
From: Joel Halpern
Sent: 14 October 2022 13:56
To: adr...@olddog.co.uk; 'SPRING WG List'
Subject: Re: [spring] SPRING WG Implementation Information Policy
We removed all references to retaining the material in the published
RFC. And emphasized that we are following
Speaking as a participant, why can they not be unnumbered IP
interfaces? No address allocation. And you can omit them from the IGP
if you want (so that it is only used by steered traffic?)
Yours,
Joel
On 11/8/2022 10:47 AM, Dongjie (Jimmy) wrote:
Hi Sasha,
Allocating IP addresses is one
At the very helpful suggestion of the nomcom chair, with text from other
WG chairs:
All,
The NomCom is tasked with selecting the IETF leadership, like the IESG
and the IAB. For the NomCom to be able to make an informed decision,
they need feedback from the wider IETF community.
Please, allo
Speaking personally, my understanding of the "stateless" aspect of SR
does not match what this email seems to describe.
SR is path stateless. There is no state related to specific paths
across the network. Any SID may be used, if it has relevant meaning, in
any path.
Advertising routers ha
This call is for the draft at:
https://datatracker.ietf.org/doc/draft-fz-spring-srv6-alt-mark
This email starts the WG adoption call for the subject draft (as
requested by the authors, with apologies from the WG chairs for how long
it has taken to kick this out.) This call will run through th
Would it make sense to note (in an operability section or similar) that
the replication behavior does under soem circumstances result in a
packet with a partially processed segment list in an SRH and a
destination address that does not appear explicitly or by mechanical
manipulation in the SRH?
m-srv6
Regards,
Giuseppe
*From:* spring *On Behalf Of *Ketan
Talaulikar
*Sent:* Friday, February 17, 2023 12:46 PM
*To:* Joel Halpern
*Cc:* SPRING WG List ; 6man
*Subject:* Re: [spring] [IPv6] WG Adoption call for Segment
Routing H
The WG Adoption call time has expired.
There was good support for the document. There were also concerns
expressed about whether there is a need for the work and how it relates
to existing RFCs. The authors have agreed to write a deployment /
operations section that better explains why one wou
The SPRING WG Chairs have noticed several recent discussions which wound
around to the question of whether specific information belongs in a
Destination Option Header (DOH) before the SHR, or belongs in an SRH
TLV. Clearly there are some pieces of information that are closely tied
to the SRH,
Robert, the SRv6 SRH specification (and b derivation all the SRv6
related specifications) is explicit that it is for use in a limited
domain. It is not intended to allow or enable SRv6 to be sent over
arbitrary portions of the Internet without suitable encapsulation (and
probably at least auth
Not quite, but close.
Routers which are not upgraded, and receive packets with the new
ethertype, will drop them. Which theoretically is fine for routers
which are not intended to be on SRv6 paths. Practically, since you want
to be able to run the paths where you need them, you probably do n
After looking at the issue of when information belongs in IPv6
destination options and when it belongs in an SRH TLV, the chairs
recommend the following:
1) Information which is generally applicable to IPv6 nodes should go
into IPv6 destination options, including the use of destination options
be
This email concludes the adoption call for
draft-fx-spring-srv6-alt-makr. The document is not adopted.
RFC 9343 provides a way to provide Alternate Marking Method in IPv6
networks.
draft-fz-spring-srv6-alt-mark is anAlternate Marking Method dedicated to
SRv6 EndPoints nodes.
Reviewing the
Thanks Eric. Trimmed, just to keep your two questions. I am speaking
as a significant contributor, but will leave text changes to the pen
holders.
Yours,
Joel
On 4/24/2023 9:12 AM, Éric Vyncke via Datatracker wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-sprin
Responding to the first comment in line as s document contributor, trimmed.
Yours,
Joel
On 4/26/2023 4:15 PM, Erik Kline via Datatracker wrote:
Erik Kline has entered the following ballot position for > draft-ietf-spring-nsh-sr-12: No Objection > > ... > >
WG Adoption"
The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state
Candidate for WG Adoption (entered by Joel Halpern)
The document is available at
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-schmutzer-spring-cs-sr-policy/__;!!OSsGDw!PrF5MLj2VoK47Bu
bandwidth, recovery, path constraints etc.) hence
i believe the draft should be adopted.
Cheers,
Daniele
On Fri, May 19, 2023 at 5:13 PM Joel Halpern
wrote:
Please give serious consideration to volunteering for the IETF nomcom.
The community needs a broad rang eof volunteers.
Thank you,
Joel
Forwarded Message
Subject:NomCom 2023 Call for Volunteers
Date: Mon, 05 Jun 2023 16:50:08 -0700
From: NomCom Chair 2023
Reply
I will leave it to the authors and shepherd to respond, including
whether to add a reference for the pseudo-code in 2.2.1.
Just to save one piece of effort, the pseudo-code technique used here
was introduced in RFC 8986, and is used in almost all the SRv6 related
drafts / RFCs. While I am not
I probably need to re-read the draft. Does the draft assume the CPE is
part of the operator domain? Remember that SRv6 MUST be used ONLY
within a limited domain?
Yours,
Joel
On 7/14/2023 2:22 AM, Weiqiang Cheng wrote:
Hi Aijun,
Thank you very much for your comments.
We will add some text t
. Otherwise, this usage violates the base rules for SRv6.
Personally, I would like to see this fixed before adoption completes.
Yours,
Joel
On 7/14/2023 9:44 AM, Joel Halpern wrote:
I probably need to re-read the draft. Does the draft assume the CPE
is part of the operator domain? Remember that
s you very well know
the history is not a very technical thing ...
On Fri, Jul 14, 2023 at 5:08 PM Joel Halpern wrote:
Speaking as an individual participant, it seems to me that the
description of using CPE as SRv6 endpoints needs to state
explicitly and clearly that this assumes
gnize that I am actually sending v6 packets with
extension headers and drop those ... but this is not a concern for
this thread nor for IETF. In such a case I will would switch an ISP :)
Cheers,
R.
On Fri, Jul 14, 2023 at 5:33 PM Joel Halpern wrote:
Nope.
The host case for SRv6 i
tection or data integrity
lot's of applications use app level encryption so asking for transport
tunnel security would be redundant at best.
Thx,
R.
On Fri, Jul 14, 2023 at 5:42 PM Joel Halpern wrote:
If they want to specify in the draft that the CPE are operator
managed by a single ope
t 6:15 PM Joel Halpern
wrote:
If a deployment of SRv6 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.
Yo
ise irrespective if authors add proposed text or not the
behaviour will be identical in practice.
Kind regards,
Robert
On Fri, Jul 14, 2023 at 6:27 PM Joel Halpern wrote:
You may not subscribe to the notion of limited domains. But the
RFCs do. Hence, the WG is required to do so.
As per the discussions on list and at IETF 117, the SPRING WG chairs
(myself and Alvaro specifically) are attempting to determine if we can
close the open issues regarding
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
The editors have entered proposed resolutions for
Speaking personally, not as chair.
As far as I know, there is no need for an update to 8200 for this
quasi-problem.
Let's state the problem with or without SRH.
If two trusted hosts inside a trusted domain that uses SRv6 are
communicating, and the path they wish to select has more than one h
ggested, I am opening a separate thread that includes SPRING and 6MAN.
Cheers,
Tal.
On Wed, Aug 2, 2023 at 4:52 PM Joel Halpern wrote:
Speaking personally, not as chair.
As far as I know, there is no need for an update to 8200 for this
quasi-problem.
Let's state the problem with or witho
So folks don't get confused, later today I will be issueing calls to
confirm the editor's conclusions on issues #3, #4, and #5. Those will
run for 2 weeks. The call for issue #1 continues, and the call for
issue #2 will be issued next week.
Yours,
Joel
__
For now speaking personally, although this may require chairs'
intervention, I do not find the trust domain text to be sufficient.
While I am not sure it would suffice, I would expect the text that goes
with figure 1 to explicitly state both that the CPE are under operator
control and that th
the potential for cooperation and trust among multiple
operators in practical applications.
B.R.
Weiqiang
*From:* Joel Halpern <mailto:j...@joelhalpern.com>
*Date:* 2023-08-07 22:10
*To:* Weiqiang Cheng <mailto:chengweiqi...@chinamobile.com>;
spring <mailto:sprin
Issue #3 in the datatracker reads
The definition for the SegmentsLeft field of the SRH as currently stated
in [RFC8754][RFC8200] no longer holds true in the presence of C-SIDs.
This definition needs to be updated to still hold true in the presence
of C-SIDs.
The response from the document ed
Issue #4 reads:
In some cases it is possible that the SR policy can be expressed purely
with C-SIDs without requiring an SRH. In this case, to allow the SR
domain to fail closed, some form of filtering based on the LOC part of
the SRv6 SID is required as relying purely on the presence of an SR
Issue #5 reads:
The use of C-SIDs might cause some difficulty in troubleshooting error
conditions signaled by ICMPv6. Section 5.4 of [RFC8754] describes the
ICMPv6 error processing that is required to be performed on the SR
Source Nodes to correlate packets since the Destination Address of the
uot;
Including such text would provide a clearer expression of the
author's understanding of the concept of a trusted domain and
remind readers to consider the potential for cooperation and
trust among multiple operators in practical applications.
B.R.
Weiqiang
gards,
Weiqiang
---原始邮件---
* 发件人:* Joel Halpern
* 发送时间:* 2023-08-09 20:30:49
* 收件人:* Weiqiang Cheng
spring
* 主题:* Re: [spring] FW: New Version Notification
fordraft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt
I look forward to seeing a draft with these changes.
Yours,
Joel
O
As mentioned earlier, we also need to confirm the resolution of issue #2
on the subject document.
This call will run for 1 week. Please speak up if you either support
closing this issue or see aspects that need further discussion or
different resolution.
Issue 2 reads:
As reminded in the c
The chairs have observed the discussions, and appreciate the responses
from the working group.
With regard to issues 2 - 5, we consider that the WG has agreed to the
proposed resolutions. We will close these issues promptly.
With regard to issue 1, while there was a lot of support for closin
Speaking as an individual contributor.
I may be misreading this. It looks like the first draft depends upon a
definition of a valid or invalid segment list, but does not provide a
definition for that. It looks like the second draft provides a precise
definition for an invalid segment list.
Hmmm. I think what confused me is that I don't see an explicit
reference to the RFC 9256 segment-list invalid rule, only a reference to
the candidate path validity. Seems easily fixed?
Would it make sense for that fix to have text along the lines of "other
segment-list validity criteria may
Askign as a participant:
In section 10.1 it says:
When the SRv6 SID in the destination address of the ICMPv6 echo request
is one of the SID flavors defined in this document, the SR source node
MUST set the arguments of the SID to 0
What is a receiver required to do if it gets an improper ICM
While we await further discussion between commentors and editors (and
the WG as a whole) on draft-ietf-spring-srv6-srh-compression, I am
looking for at least two volunteers (more are welcome).
One volunteer is for a slightly unusual ask. I am looking for someone
who is interested in SRv6 and
been involved in implementation nor reading the draft
repeatedly.
Linda
-Original Message-
From: spring On Behalf Of Joel Halpern
Sent: Wednesday, September 6, 2023 11:11 AM
To: SPRING WG List
Subject: [spring] Volunteers for the SPRING SRv6 Compression draft
While we await further discu
In case my reply here confused folks, more reviewers is better. This
reply was not intended to cut off offers from folks.
Thank you,
Joel
On 9/6/2023 12:23 PM, Joel Halpern wrote:
Thank you Linda. That would be very helpful. Let's wait little bt
for revisions, and then I would appre
2023 at 16:38:30, Joel Halpern wrote:
Askign as a participant:
In section 10.1 it says:
When the SRv6 SID in the destination address of the ICMPv6 echo
request is one of the SID flavors defined in this document, the SR
source node MUST set the arguments of the SID to 0
What is a receiver
7 Sep 2023 at 14:49:20, Joel Halpern wrote:
Can you explain then what the text is section 10.1 is talking about?
It seems like it is mandating certain bits being 0 for it to be
considered a match? (I will also have to find out more about why the
tests showed certain routers dropping such
Thank you Francois (and the editorial team.)
We received a number of offers for reviews of the kind I requested.
Responders, please go ahead and review this version. If anyone who did
not respond wishes to review, you are mor ethan welcome. We cannot
possibly have too many reviews.
Thank y
Please give feedback to the nomcom.
Yours,
Joel
Forwarded Message
Subject:NomCom 2023 Needs Your Feedback
Date: Sun, 05 Nov 2023 22:26:13 -0800
From: NomCom Chair 2023
Reply-To: nomcom-chair-2...@ietf.org
To: IETF Announcement List
Hi,
The NomCom
To clarify one question I noted in the below agreements, once all the
open isues have been closed, I expect that the editors will remove the
appendix that tracks them. We asked that they be included in the draft
so that WG participants would be more aware of them (as people often do
not look a
1 - 100 of 154 matches
Mail list logo
