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
There have been some questions raised about the relationship between the
various SRv6 documents and the ongoing effort to create a starting point
for a WG document on SRv6 security. In the opinion of the chairs, while
we would appreciate better security considerations in all documents, we
do n
I have closed the remaining issue in the issue tracker (issue #1).
Authors, I believe you have a set of changes under way? When those are
ready, please resubmit removing the open issues section of the document.
Meanwhile, if anyone has concerns that issues with this document please
speak up.
-srh-compress...@ietf.org,
spring-cha...@ietf.org
The IETF WG state of draft-ietf-spring-srv6-srh-compression has been changed
to "In WG Last Call" from "WG Document" by Joel Halpern:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
Comment:
This sta
1) This email initiates an IPR call for the subject document. All
authors and contributors, please confirm explicitly to the list that all
known relevent IPR has been disclosed. Or tell us if that is not the case.
2) Pablo Camarillo has offered to serve as document shepherd for this
document,
Speaking as an individual participant, as I understand it the
consideration is one of space vs state tradeoff. In the extreme, using
a binding MPLS SID at every hop is essentially classical MPLS, and needs
a means to create state in every node along the path to know how it
processes the bindin
Looking at this draft, I am trying (as a participant) to understand the
SIDs as they will appear in packets.
In the case of SR-MPLS, will the micro-tap SID come from the block
associated with the processing node? If so, how do we avoid collision
between the microtap SID and the node's own SID
(Speaking technically as an individual, but noting that Alvaro and I are
the responsible chairrs who will have to resolve any technical standards
incompatibility. And I have not talked with Alvaro. So I may be
putting my foot in my mouth.)
As I understand it, the current view is that the com
The WG LC has not been closed because it is clear that the discussion of
issues is ongoing. Declaring a conclusion seems to this chair to be
inappropriate. The rules are very clear that the time limit when we
start a call is a guideline. Chairs are not free to cut off unresolved
discussions
While different WGs use issue trackers differently, in SPRING we
consider the email list the primary source of information. We use the
issue tracker to help us track long term issues. We also use it when
the chairs when to be explixcit about how we understand the issue. At
the current time,
Robert, as far as I can tell, you are asking for a different change than
any of the other proposals. If I understand, you are proposing that
even end hosts inside an SRv6 domain should encapsulate the underlying
IPv6 packet. In order to help the chairs keep track, and tell if there
are other
Can the authors (and listed contributors) please confirm to the working
group email list that all IPR believed to be relevant which is known to
the author (or contributor) has been disclosed as per the IETF rules.
Once that is done, the chairs will start the working group adoption call
for thi
There are two cases covered in section 6.5 of the compression draft that
appear to be at variance with secton 8.1 of RFC 8200.
First, if the final destination in the routing header is a compressed
container, then the ultimate destination address will not be the same as
the final destination sh
t talk about SRH nor cSIDs, but provides a hint on
how to handle such future situations.
With that being said I would like to still understand what real
problem are we hitting here ...
Kind regards,
Robert
On Wed, Apr 3, 2024 at 11:09 PM Joel Halpern wrote:
There are two cases covered i
e original protocol RFC to check if
this is ok or not. If that would not be a normal process I bet we
would still be using classful IPv4 routing all over the place.
Regards,
Robert
On Wed, Apr 3, 2024 at 11:28 PM Joel Halpern wrote:
The concern with regard to the text that the chairs
1 - 100 of 171 matches
Mail list logo
