That does summary below does not match what others have said on this thread.
Yours,
Joel
On 4/14/2022 12:23 PM, Andy Bierman wrote:
On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee)
mailto:40cisco@dmarc.ietf.org>> wrote:
While RFC 4001 really didn't need to extend the zone index
have reason to
believe there aren't any significant usages of the ip-address types where zone
is accepted. Show me the models
Acee
On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern" wrote:
Do we have reason to believe that no one outside the IETF has used
ip-add
Do we have reason to believe that no one outside the IETF has used
ip-address as we published in ways that need a zone?
It seems to me that the first step in the plan below is reasonable. But
changing ip-address itself seems a bad idea. If one means no-zone, use
the -no-zone typedef.
that no one uses the zone field would seem
the reasonable and impossible bar for doing such.)
Yours,
Joel
On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote:
Hi Joel,
On 4/7/22, 1:18 PM, "Joel M. Halpern" wrote:
Acee, I am missing something basic.
It seems to me that it wou
Acee, I am missing something basic.
It seems to me that it would be very wrong for the LSR YANG module to
demand a change to an important type because it turns out that type
doesn't mean what LSR thought it meant. Such an error is LSR's problem,
not the underlying modules.
There seem to be
If you want to experiment with unusual metrics, and minimize the degree
to which you need consistency, maybe you should look at running a
different routing protocol in this limited domain? Rather than trying
to make IS-IS and OSPF do something they are not designed for? (While
there are
In earlier emails, we brought
https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-02 to the
attention of the working group.
This draft was written to provide an explanation of how the 303 ifType
code point that was assigned at Ericsson's request could be used. It
builds on RFC
alf Of tom petch
Sent: Wednesday, June 23, 2021 1:43 AM
To: Joel M. Halpern ; Harold Liu
; lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern
Sent: 22 June 2021 09:57
Do Les' suggested edits address your concerns.
We will apply yor changes t
We have submitted a revision which we hope addresses the comments we
have received. Further feedback is appreciated.
Yours,
Joel
PS: I think one of the effects of the changes is to better align the
content with the intended informational status. It should be clear now
that it is
Do Les' suggested edits address your concerns.
We will apply yor changes to the IANA considerations section.
Yours,
Joel
On 6/22/2021 4:34 AM, tom petch wrote:
From: Joel M. Halpern
Sent: 21 June 2021 15:13
Tom, 5309 did not define the ifType. Go read 5309. You seem to have
gotten confused
o claim a
reference, but if it is it should only be in addition to the existing reference.
Les
-Original Message-
From: Lsr On Behalf Of Joel M. Halpern
Sent: Monday, June 21, 2021 7:13 AM
To: tom petch ; Harold Liu
; lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-liu
-
From: mohamed.boucad...@orange.com
Sent: Thursday, June 17, 2021 2:16 PM
To: Joel M. Halpern ; draft-liu-lsr-p2pover...@ietf.org
Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Hi Joel, all,
Please find some quick comments to this draft, fwiw:
* pdf:
https://protect2.fire
mes an RFC.)
Yours,
Joel
On 6/18/2021 12:20 PM, tom petch wrote:
From: Joel M. Halpern
Sent: 18 June 2021 16:29
Tom, I am not sure what you mean by "the update has happened"> The code
point has been assigned. Assuming this document becomes an RFC, it will
be significantly cleare
s that update.
Yours,
Joel
On 6/18/2021 7:47 AM, tom petch wrote:
From: Lsr on behalf of Joel M. Halpern
Sent: 16 June 2021 21:46
This document (and the code point) are intended to be in line with 5309.
I believe they are. If we got it wrong, please help us fix it.
A reference would be reas
,
Acee
On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern" wrote:
Recently, Ericsson requested and received an IF Type assignment from
IANA (with expert review) for point-to-point over Ethernet links.
It was noted during the discussion around the assignment that
Recently, Ericsson requested and received an IF Type assignment from
IANA (with expert review) for point-to-point over Ethernet links.
It was noted during the discussion around the assignment that a document
(eventually, we hope, an RFC) describing how to use that and why we
asked for it
I have been watching this debate, and I am left with the impression that
the information being defined in section 9 of this draft is simply not
useful for routing. It confuses operational information with routing
information. Given taht the information has to come from somewhere
outside the
I have read this draft, and followed the discussion on the list.
This seems a useful and sensible piece of work. I support adoption.
Yours,
Joel
On 12/1/2020 4:12 PM, Acee Lindem (acee) wrote:
This IP Flex Algorithm draft generated quite a bit of discussion on use
cases and deployment prior
Just to confirm, yes, that change Peter has made removing END.T resolves
my concerns.
Thanks,
Joel
On 10/8/2020 9:38 AM, Peter Psenak wrote:
Hi Chris,
please see inline:
On 02/10/2020 12:32, Christian Hoppsprotocol= application/pgp-signature
wrote:
Thanks for the update, a couple issues
I am missing something in this discussion of multiple algorithms.
My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is
that you need to associated a forwarding label (e.g. MPLS label or IPv6
address) with a specific algorithm so that you can compute the next hope
for the
/29/2020 4:39 AM, Peter Psenak wrote:
Joel, Ketan,
On 28/09/2020 15:25, Ketan Talaulikar (ketant) wrote:
Hi Joel,
Please check inline below.
-Original Message-
From: Lsr On Behalf Of Joel M. Halpern
Sent: 25 September 2020 19:08
To: Ketan Talaulikar (ketant) ;
lsr@ietf.org
Subject
Of Joel M. Halpern
Sent: 25 September 2020 03:18
To: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt
First, there is a slight confusion in the way I formed the quesiton, but I
think it still applies.
The piece of this draft is section 9
First, there is a slight confusion in the way I formed the quesiton, but
I think it still applies.
The piece of this draft is section 9, which advertises the length of the
arg portion of the SID. But does not provide specific meanings for
specific values.
The example of an ARG in the
Les, maybe I am missing your point, but it sounds like what you are
asking for is a (better?) version of the micro-loop prevention work, so
as to mitigate the interaction between inconsistent convergence and
fast-reroute?
Yours,
Joel
On 5/6/2020 1:53 PM, Les Ginsberg (ginsberg) wrote:
Bruno
Robert, you seem to be asking that we pass full information about the
dynamic network state to all routers so that they can, if needed, serve
as fully intelligent path computation engines. If you want to do that,
you will need more than just the telemetry. You will need the demands
that are
公司研究院
+86-10-50902116
*From:* Joel M. Halpern <mailto:j...@joelhalpern.com>
*Date:* 2020-03-26 21:35
*To:* xie...@chinatelecom.cn <mailto:xie...@chinatelecom.cn>; lsr
<mailto:lsr@ietf.org>
*Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
this helps.
Chongfeng
*From:* Joel M. Halpern <mailto:j...@joelhalpern.com>
*Date:* 2020-03-25 21:52
*To:* xie...@chinatelecom.cn <mailto:xie...@chinatelecom.cn>; lsr
<mailto:lsr@ietf.org>
*Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
Rou
This drafts starts by asserting that there are limitations on what can
be done with the existing technology. As the description is quite
vague, I can not be certain. But I do not know of any difficulty in
providing the described capabilities with current technology, without
introducing a
It does seem to me that using a registry to capture the relationship
between the OSPF or IS-IS advertisement (TLV, sub-TLV, ...) and the SR
behavior (as defined in the NP registry and subsequent additions) is
useful. I would not want to have to respin the base draft to add
additional
29 matches
Mail list logo
