Please consider volunteering for the nomcom. The IETF needs a broad
range of people on the nomcom, and that requires a very broad range of
volunteeers.
Thank you,
Joel
Forwarded Message
Subject:Nomcom 2024-2025 Third Call For Volunteers
Date: Thu, 06 Jun 2024
The question, as I understand it, is not what you want Dino. Nor is it
what Luigi wants. It is what the working group wants. I gather that
Padma has the task of figuring that out. Good luck Padma.
Yours,
Joel
On 5/30/2024 12:17 PM, Dino Farinacci wrote:
On May 30, 2024, at 6:07 AM,
Looking at drafts, I noticed that draft-ietf-teas-nrp-scalability says
that one is required (? expected? needs to?) use an NRP separate from
the path control information.
However, the Spring adopted draft
draft-ietf-spring-resource-aware-segments puts the NRP selection in the
segment
Reviewer: Joel Halpern
Review result: Ready with Nits
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
Nomcom is looking for volunteers.
Yours,
Joel
Forwarded Message
Subject:Call for volunteers
Date: Wed, 08 May 2024 13:09:17 -0700
From: NomCom Chair 2024
Reply-To: nomcom-chair-2...@ietf.org
To: IETF Announcement List
CC: i...@ietf.org
The
If you sent email today and did not see a copy on the list, this may be
why...
Yours,
Joel
Forwarded Message
Subject: Update on ongoing mail delivery issues and request to resend
failed messages
Date: Thu, 9 May 2024 14:29:06 -0500
From: Robert Sparks
Reply-To:
-tcpoptions-and-v6eh/genart-review/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt
-Message d'origine-
De : Joel Halpern via Datatracker
Envoyé : vendredi 3 mai 2024 05:01
À : gen-...@ietf.org
Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
c...@ietf.org; opsawg@ietf.org
Objet : Genart
-tcpoptions-and-v6eh/genart-review/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt
-Message d'origine-
De : Joel Halpern via Datatracker
Envoyé : vendredi 3 mai 2024 05:01
À : gen-art@ietf.org
Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
c...@ietf.org; ops...@ietf.org
Objet : Genart
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
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
To make sure I am understanding your reasoning
It appears to me that you are saying that as you understand
draft-ietf-spring-resource-aware-segments, it does not allow for using
different SIDs on the same node to represent sending different sets of
traffic through different queues on the
It's up to Luigi and Padma, but my read is that if it was private it was
not a WG decision.
Yours,
Joel
On 4/26/2024 6:05 PM, Dino Farinacci wrote:
Can you find an on-list email where such a conclusion was reached. That would
certainly explain your choice.
I searched (before I sent the
Can you find an on-list email where such a conclusion was reached. That
would certainly explain your choice.
Yours,
Joel
On 4/26/2024 5:15 PM, Dino Farinacci wrote:
I gather you decided to change the encoding to match some other work. But you
chose not to use a different code point when
I am not following your reasoning.
I gather you decided to change the encoding to match some other work.
But you chose not to use a different code point when you did so. You
simply changed the meaning, without updating the published RFC.
Sorry, that is squatting on and misusing a code
of these conditions the only reasonable action IMO is to
use a different type value.
Ciao
L.
On 23 Apr 2024, at 18:24, Joel Halpern wrote:
From where I sit, doing nothing should be a non-starter. We have a
published RFC. We are allowed to change our mind.
But...
1) We need to be explicit
From where I sit, doing nothing should be a non-starter. We have a
published RFC. We are allowed to change our mind.
But...
1) We need to be explicit about making such a change. Which involves
updating the existing RFC.
2) Any such change needs to explain why it is being changed. Just
The chairs have observed and appreciated the discussion of the questions
that have been raised regarding the spring compression draft.
We believe the discussion has run its useful course. Based on the
discussion, we are asking for one clarification to be added to the
draft. Following that,
of such traffic, although how it will obtain that information may
depend on its implementation.
Thanks,
Francois
On 9 Apr 2024 at 00:34:43, Joel Halpern wrote:
Note as an observer of this discussion:
If we consider that the need for configuration of observer nodes is
an issue, I am pretty
Note as an observer of this discussion:
If we consider that the need for configuration of observer nodes is an
issue, I am pretty sure we need to remember that it is not just the SID
block that needs to be known. The compressed SID length and flavor also
need to be known.
Yours,
Joel
On
nt endpoint should know uSIDs in
entire container/carrier ?
Thx,
R.
On Fri, Apr 5, 2024 at 4:26 PM Joel Halpern wrote:
I think I understand your description. At base, I think you are
arguing that a compresssed container should be understood to be a
representation of a segmen
ng a uSID list by just specifying the uSID as the DA?
> Yours,
> Joel
>
>
>
> Sent via the Samsung Galaxy S20 FE 5G, an AT 5G smartphone
>
>
> Original message
> From: Francois Clad
> Date: 4/4/24 1:10 PM (GMT-05:00)
> To: Joel Halpern
> Cc: S
the Samsung Galaxy S20 FE 5G, an AT 5G smartphone
Original message
From: Francois Clad
Date: 4/4/24 1:10 PM (GMT-05:00)
To: Joel Halpern
Cc: SPRING WG List , Robert Raszuk
, Andrew Alston - IETF
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6
ument via a segment list, the SR source
node MUST construct the IPv6 packet as described in Section 6 and
compute the ICMPv6 checksum as described in Section 6.5."
Please let me know if anything in this text is not clear.
Thanks,
Francois
On 4 Apr 2024 at 16:10:11, Joel Halpern
wrote
.
This is broken – severely broken.
Andrew
*
*
*
Internal All Employees
From: *spring on behalf of Francois Clad
*Date: *Thursday, 4 April 2024 at 14:49
*To: *Joel Halpern
*Cc: *SPRING WG List , Robert Raszuk
*Subject: *Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh
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
ut 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 in s
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
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
Reviewer: Joel Halpern
Review result: Ready with Nits
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
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
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,
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
(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
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
I checked with the IETF's liaison manager for ITU-T. It turns out,
process-wise, that the underlying document this refers to was fully
approved by ITU-T in December. So there is nothing to respond to and
no benefit for the IETF in generating a response.
Yours,
Joel
On 2/17/2024 12:13 AM,
s.ietf.org/iddiff?url1=draft-ietf-bier-tether-04=draft-ietf-bier-tether-05=--html
Thanks.
Jeffrey
Juniper Business Use Only
-Original Message-----
From: Joel Halpern
Sent: Thursday, February 15, 2024 11:27 PM
To: Jeffrey (Zhaohui) Zhang ; gen-art@ietf.org
Cc: b...@ietf.org; draft-ietf-b
, that is the
point. It just works.)
Yours,
Joel
On 2/15/2024 11:04 PM, Jeffrey (Zhaohui) Zhang wrote:
Hi Joel,
Thanks for your review and comments.
Please see zzh> below.
Juniper Business Use Only
-Original Message-
From: BIER On Behalf Of Joel Halpern via Datatracker
Sent: Thursday, February
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
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
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 treat these comments just
like any other last call comments.
For more
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
-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
ability and provides a valid solution for building NRPs
in a limited scope.
Hope this solves your concerns about the maturity and scalability of this
mechanism.
Best regards,
Chongfeng
From: Les Ginsberg \(ginsberg\)
Date: 2024-01-11 08:21
To: Joel Halpern; Acee Lindem; t...@ietf.org;
My reading as shepherd of the inclusion of the mitigation references was
that it constituted a fair effort to recognize that the community hadd
not and was not ignoring these issues, and that any effort to better
address the issues should be aware of the existing mitigation efforts.
As an
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.
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
Given that the documents that provide the basic definitions needed for
this are still active Internet Drafts, it seems premature to last call
this document.
As a lesser matter, it seems odd that
draft-ietf-teas-ietf-network-slices, which defines the terms needed to
understand this draft, is
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
in the introduction as well,
we can fix it with the RFC editor.
Thanks & Cheers
Bala'zs
-Original Message-
From: Joel Halpern via Datatracker
Sent: Tuesday, December 19, 2023 3:39 PM
To: gen-art@ietf.org
Cc: det...@ietf.org; draft-ietf-detnet-mpls-over-ip-preof@ietf.org;
last-c...@ietf.org
Sub
Reviewer: Joel Halpern
Review result: Ready with Nits
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
, 2023 4:23 PM
To: Joel Halpern ; gen-art@ietf.org
Cc: b...@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org
Subject: RE: Genart early review of draft-ietf-bess-bgp-multicast-05
Hi Joel,
Thanks for your review and comments.
I will address them and come back.
Jeffrey
-Original Message
, 2023 4:23 PM
To: Joel Halpern ; gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org
Subject: RE: Genart early review of draft-ietf-bess-bgp-multicast-05
Hi Joel,
Thanks for your review and comments.
I will address them and come back.
Jeffrey
-Original Message
becomes
more and more mobile and more and more interplanetary. I think that should
already be
of interest to Intarea.
Fred
-Original Message-
From: Joel Halpern
Sent: Monday, November 13, 2023 1:59 PM
To: Templin (US), Fred L
Cc: int-area@ietf.org
Subject: [EXTERNAL] Re: [Int-area
Top posting two small but important points to Fred:
1) Changing Ethernet CRC behavior is up to IEEE. IETF is not free to
redefine that.
2) There are approaches for links with long delays (sometimes even
longer than the 8 minutes to which you refer). If you want to propose
different
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
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
that there are metrics that both care about, but most of
the ones I can see to start from are quite distinct.
Yours,
Joel
On 11/2/2023 5:31 PM, LUIS MIGUEL CONTRERAS MURILLO wrote:
Hi Joel, all,
Please, see in-line
Best regards
Luis
*De:* Cats *En nombre de * Joel Halpern
*Enviado el:* jueves, 2 de
There are, as far as I can tell, two very valid and very different
approaches to service selection / traffic direction. It can be done by
the application, or it can be done by the operator edge. CATS is
chartered to address the operator-based approach. Applications clearly
can chose to make
Reviewer: Joel Halpern
Review result: Not Ready
This is a requested genart early review of
draft-ietf-bess-bgp-multicast-05
Prepared on 23-Oct-2023
Summary: This draft is not ready, having a number of issues that need to be
addressed.
I presume this draft will be socialized with the PIM
Reviewer: Joel Halpern
Review result: Not Ready
This is a requested genart early review of
draft-ietf-bess-bgp-multicast-05
Prepared on 23-Oct-2023
Summary: This draft is not ready, having a number of issues that need to be
addressed.
I presume this draft will be socialized with the PIM
Thank you. That fully resolves my concern.
Yours,
Joel
On 10/16/2023 4:26 PM, Dino Farinacci wrote:
Yes, that would do it.
Please ack if these diffs satisfy your comments.
Thanks,
Dino
___
lisp mailing list
lisp@ietf.org
Yes, that would do it.
Yours,
Joel
On 10/16/2023 3:41 PM, Dino Farinacci wrote:
I can change the spec to be more specific as you suggest. Would that work for
you?
Dino
On Oct 16, 2023, at 12:38 PM, Joel Halpern wrote:
To point to one example of the problem, this draft defines "
To point to one example of the problem, this draft defines "push based"
as using multicast. Decent uses multicast. But not all push based
systems use multicast. The definitions of push-based and pull-based
should be general. Decent-pulll and decent-push (or some other terms)
can be defined
I have a relatively minor teminological problem with this draft. (I have
no opinion as to whether technologically it is a good idea for the LISP
WG to adopt it.)
Relative to the LISP mapping system, the terms pull-based and push-based
long predate this draft. There was an original push-based
ly helpful.
Pedantically, suppose there was an author on the old draft who is not
an author on the new draft?
(I think we are into esoteric grounds here, but just wondering.)
A
*From:*Joel Halpern
*Sent:* 06 October 2023 14:08
*To:* adr...@olddog.co.uk; 'Matthew Bocci (Nokia)'
; bess@ietf.org
*
Not speaking for the trust, but as someone who has worked in the rights
pace for IETF for quite some time, if the authors update the rights
grant to grant the needed rights (by replacing the boilerplate), then
the new draft grants the needed rights. They have legal ability to make
such a
My thanks to the chairs. That looks like a reasonable, achievable, and
useful set of goals for the working group.
Yours,
Joel
On 10/1/2023 1:46 PM, Padma Pillay-Esnault wrote:
Hello all,
We have created a repository to gather input for the proposed LISP WG
charter presented in our last
cloud resources."
Yours,
Joel
On 9/21/2023 2:28 PM, Linda Dunbar wrote:
Joel,
Thank you very much for the additional comments.
Resolutions to your comments are inserted below:
Linda
-Original Message-
From: Joel Halpern
Sent: Wednesday, September 20, 2023 5:45 PM
To: draft-ietf-rtg
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
On 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
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
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 appreciate
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 discussion
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
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
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
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
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.
are not aggregated
nicely, which is very common, one single site failure can trigger a
huge number of BGP UPDATE messages. There are proposals, such as
[METADATA-PATH], to enhance BGP advertisements to address this problem.”/
//
Linda
*From:* Joel Halpern
*Sent:* Tuesday, August 22, 2023 6:03 PM
ote:
Joel,
I see your points. Please see my explanation below quoted by .
*From:* Joel Halpern
*Sent:* Monday, August 21, 2023 11:34 PM
*To:* Linda Dunbar
*Cc:* rtgwg-chairs ;
draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org; rtgwg@ietf.org
*Subject:* Re: Need your help to make sure
Thank you Linda. Trimmed the agreements, including acceptable text from
your reply. Leaving the two points that can benefit from a little more
tuning.
Marked
Yours,
Joel
On 8/22/2023 12:12 AM, Linda Dunbar wrote:
Similarly, section 3.2 looks like it could apply to any operator.
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
,
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
On 8/9
ding 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
*From:* Joe
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
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
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
ooperation 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:spring@ietf.org>
*
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
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
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 without SR
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
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
e 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. A
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
on 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 singl
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
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 that
. 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
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
1 - 100 of 515 matches
Mail list logo
