Peter,
Please see inline:
*From:*Peter Psenak <mailto:ppse...@cisco.com>
*Sent:* Thursday, March 21, 2024 5:39 PM
*To:* Dongjie (Jimmy)
<mailto:jie.dong=40huawei@dmarc.ietf.org>; Les Ginsberg
(ginsberg) <mailto:ginsb...@cisco.com>;
lsr@ietf.org;
Hi Jie,
On 02/04/2024 10:18, Dongjie (Jimmy) wrote:
Hi Peter,
Please see inline:
*From:*Peter Psenak
*Sent:* Thursday, March 21, 2024 5:39 PM
*To:* Dongjie (Jimmy) ; Les
Ginsberg (ginsberg) ; lsr@ietf.org;
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
*Subject:* Re: [Lsr] Comments
PA signal.
thanks,
Peter
Regards,
Muthu
On Fri, Mar 22, 2024 at 6:44 PM Peter Psenak wrote:
Muthu,
On 18/03/2024 10:41, Muthu Arul Mozhi Perumal wrote:
Hi all,
draft-ietf-lsr-igp-ureach-prefix-announce mentions BGP PIC edge
as one the use cases for UPA in the prese
Kotesh,
On 19/03/2024 12:44, Kotesh Chundu wrote:
Hi,
I have one query regarding the following content from the IGP UPA draft.
As UPA advertisements in IS-IS are advertised in existing Link State
PDUs (LSPs) and the unit of flooding in IS-IS is an LSP,*it is recommended that, when
Muthu,
On 18/03/2024 10:41, Muthu Arul Mozhi Perumal wrote:
Hi all,
draft-ietf-lsr-igp-ureach-prefix-announce mentions BGP PIC edge as one
the use cases for UPA in the presence of summarization. However, it is
not quite clear whether UPA is expected to trigger BGP best path
calculation at
Robert,
On 21/03/2024 20:52, Robert Raszuk wrote:
Peter,
Ok I think what you are proposing is pretty granular and that is fine.
We may still disagree if link should be used at all if there are
errors on this link in *ANY* direction.
So my suggestion here is to have that support build in as
Hi Robert,
On 21/03/2024 18:26, Robert Raszuk wrote:
Hey Peter,
Why do we need the notion of "reverse direction" to be any
different then
the notion of forward direction from node B to A on a link ?
For a link A->B, we typically use attributes in the direction
A->B.
aft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt is now
available. It is a work item of the Link State Routing (LSR) WG of
the IETF.
Title: IGP Flexible Algorithms Reverse Affinity Constraint
Authors: Peter Psenak
Jakub Horn
Amit Dhamija
N
Hi Jie,
On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,
Thanks for providing your opinion with an example.
In your example, the default IGP metric is used, which is normally
calculated based on bandwidth. While Flex-Algo can support metric
types such as TE metric and delay.
When
ter
thanks
-- tony
On Wed, Mar 20, 2024 at 6:22 PM Peter Psenak wrote:
Tony,
there are two use cases:
1. Your application wants to exclude address that is anycast - an
example of where this can be used internally by IGP is a TI-LFA or
uloop, when picking up the address
Tony,
there are two use cases:
1. Your application wants to exclude address that is anycast - an
example of where this can be used internally by IGP is a TI-LFA or
uloop, when picking up the address of the node over which we want to do
the enforcement. There is a N bit as well, but in case
Hi Acee,
I am not aware of any IPR related to this document.
Thanks,
Peter
On 19/03/2024 19:33, Acee Lindem wrote:
Co-Authors,
Are you aware of any IPR that applies to draft-chen-lsr-anycast-flag?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879,
I support the adoption of the draft as a WG document.
thanks,
Peter
On 23/02/2024 06:27, Yingzhen Qu wrote:
Hi, This email begins a 2 week WG adoption poll for the following
draft:
https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/Please
review the document and indicate
Hi Acee,
I am not aware of any undisclosed IPR related to this document.
thanks,
Peter
On 19/02/2024 23:20, Acee Lindem wrote:
Co-Authors,
Are you aware of any IPR that applies to draft-ietf-lsr-flex-algo-bw-con-07.txt?
If so, has this IPR been disclosed in compliance with IETF IPR rules
Hi,
I don't believe any of what is being proposed in the draft is necessary.
There are existing mechanism available to advertise an inter-AS link.
Using the prefix advertisement to pair the two ends of the inter-AS link
is a bad idea IMHO. There are better ways of doing it - e.g.
Hi LSR Chairs,
I would like to ask for an early IANA allocation for the two new prefix
attributes flags as specified at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-01#name-iana-considerations
For ISIS, the allocations of two new Prefix Attributes Flags
Hi LSR Chairs,
I would like to ask for an early IANA allocation for the FAD sub-TLVs as
specified at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-flex-algo-reverse-affinity-01#section-11
There is a shipping implementation of the draft and we would like to
secure the code points
Hi Shraddha,
On 22/11/2023 12:58, Shraddha Hegde wrote:
I support the adoption of the document.
I have below comments
1. It is not clear whether " OSPFv2 Prefix Attributes Sub-TLV" and "OSPFv3 Prefix
Attributes Sub-TLV"
Would allow other sub-tlvs under them in future. If so, the flags should
Changwang,
On 22/11/2023 04:40, linchangwang wrote:
Hi Acee and WG，
I support the adoption of this draft as it provides a solution to
effectively address the problem of insufficient existing flags for
OSPFv2/OSPFv3. Additionally, it significantly enhances protocol extension
Hi Yingzhen,
I support the adoption. Multiple implementations already support what
the draft is proposing.
thanks,
Peter
On 17/11/2023 18:23, Yingzhen Qu wrote:
Hi,
This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv:
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS
Hi Acee,
I'm not aware of any IPR that applies to
draft-chen-lsr-prefix-extended-flags-03.
thanks,
Peter
On 17/11/2023 16:48, Acee Lindem wrote:
Co-Authors,
Are you aware of any IPR that applies to
draft-chen-lsr-prefix-extended-flags-03?
If so, has this IPR been disclosed in compliance
Aijun,
please see inline:
On 06/11/2023 13:23, Aijun Wang wrote:
Hi, all:
Here are some technical questions for the hurry adopted draft about
unreachable prefixes announcement:
1) There exists already “prefix originator” sub-TLV to indicate the
associated prefix is unreachable, what’s the
Hi John,
On 31/10/2023 23:01, John Scudder wrote:
Hi Aijun,
I apologize for the length of time it’s taken me to respond to your request.
Having now taken the time to study the question properly, including a review of
both drafts in question, the WG adoption call, and the subsequent email,
un Wang
*抄送:*Robert Raszuk ; Les Ginsberg (ginsberg)
; Huzhibo
; Peter Psenak
; linchangwang ; lsr
*主题:*Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
Hi Aijun,
When the WG discussion first indicated th
[mailto:lsr-boun...@ietf.org] *代表 *Acee
Lindem
*发送时间:*2023年9月6日0:56
*收件人:*Aijun Wang
*抄送:*Robert Raszuk ; Les Ginsberg (ginsberg)
; Huzhibo
; Peter Psenak ;
linchangwang ; lsr
*主题:*Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
Announcement" - draft-ppsenak-lsr-igp-ure
mailto:40huawei@dmarc.ietf.org>>
> Sent: Wednesday, August 30, 2023 6:33 PM
> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Peter Psenak (ppsenak)
> mailto:ppse...@cisco.com>>; linchangwang
mailto:linchangwang.04...@h3c.com>>;
> Acee Lind
ei....@dmarc.ietf.org>>; Peter Psenak (ppsenak)
mailto:ppse...@cisco.com>>; linchangwang
mailto:linchangwang.04...@h3c.com>>;
Acee Lindem mailto:acee.i...@gmail.com>>; lsr
mailto:lsr@ietf.org>>;
draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.o
Changwang,
On 30/08/2023 08:15, linchangwang wrote:
Hi WG,
When considering adoption, it's important to take into account the following
drafts as well.
Draft #1
link：https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annoucement-12.txt
Draft #2
wide. You claimed "PE may
find useful to know them". All I sad was that MSDs are orthogonal to the
summarization.
thanks,
Peter
Thx.
R.
On Tue, Aug 29, 2023 at 11:52 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote:
Robert,
On 29/08/2023 02:23,
with prefixes and
summarization.
thanks,
Peter
Thx,
R.
On Tue, Aug 29, 2023 at 10:38 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote:
Robert,
On 28/08/2023 14:19, Robert Raszuk wrote:
> Daniel,
>
> > [DV] No, there’s no need to leak and advertise
Robert,
On 28/08/2023 14:19, Robert Raszuk wrote:
Daniel,
> [DV] No, there’s no need to leak and advertise
You mean there is no need for RFC9352 in your network. If so - great.
I was however asking the question: if network needs to advertise any of
the information defined in RFC9352 would
Hi Acee,
I'm not aware of any undisclosed IPR.
thanks,
Peter
On 23/08/2023 13:02, Acee Lindem wrote:
Co-Authors,
Are you aware of any IPR that applies to
draft-posenak-lsr-igp-ureach-prefix-announce-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979,
Hi Robert,
please see inline:
On 23/08/2023 14:48, Robert Raszuk wrote:
Dear LSR WG,
I object on two basis ...
1)
The version -04 does not contain normative MUST that UPA shall only be
used to trigger invalidation when end to end encapsulation is used for
subject application(s). So as
Muthu,
On 14/08/2023 02:44, Muthu Arul Mozhi Perumal wrote:
Hi,
draft-ietf-lsr-rfc8919bis defines the F-bit in SABM as:
F-bit: Set to specify Loop-Free Alternate (LFA) (includes all LFA
types).
Does all LFA types mean LFA/RLFA/DLFA/TI-LFA as an application?
if you need to
Hi Bruno,
I will update the draft.
thanks,
Peter
On 28/07/2023 14:32, bruno.decra...@orange.com wrote:
Peter,
From: Peter Psenak
Sent: Thursday, July 27, 2023 8:00 PM
Bruno,
On 27/07/2023 16:12, bruno.decra...@orange.com wrote:
Bottom line:
- we see that this can be problematic
Bruno,
On 27/07/2023 16:12, bruno.decra...@orange.com wrote:
Bottom line:
- we see that this can be problematic in some cases
- it's very easy to fix by mandating the use of the flags(s).
I believe we understand each other. I even believe we are in a violent
agreement, although we have
Bruno,
please see inline (##PP2):
On 26/07/2023 23:34, bruno.decra...@orange.com wrote:
Peter,
From: Peter Psenak
Sent: Wednesday, July 26, 2023 11:26 PM
Bruno,
please see inline (##PP):
On 26/07/2023 22:46, bruno.decra...@orange.com wrote:
Peter,
Please see inline
From: Peter
Bruno,
please see inline (##PP):
On 26/07/2023 22:46, bruno.decra...@orange.com wrote:
Peter,
Please see inline
From: Peter Psenak
Bruno,
please see inline:
On 25/07/2023 21:11, bruno.decra...@orange.com wrote:
Peter,
Please see inline
From: Peter Psenak
Sent: Tuesday, July 25
Hi Bruno,
please see inline:
On 26/07/2023 16:38, bruno.decra...@orange.com wrote:
Peter,
please see inline
From: Peter Psenak
Sent: Tuesday, July 25, 2023 10:04 PM
Bruno,
please see inline:
On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
Peter,
Thank for you answer. Please
Robert,
On 25/07/2023 22:19, Robert Raszuk wrote:
Hey Peter and Lsr,
At the risk of being called troublemaker by Les again :) can you refresh
my failing memory how UPA would work in case of Inter-AS option C (where
original next hops are maintained for service routes across two or more
Bruno,
please see inline:
On 25/07/2023 21:11, bruno.decra...@orange.com wrote:
Peter,
Please see inline
From: Peter Psenak
Sent: Tuesday, July 25, 2023 6:49 PM
Bruno,
please see inline:
On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
Peter,
Thanks for your answer.
Please see
Bruno,
please see inline:
On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
Peter,
Thank for you answer. Please see inline [Bruno]
From: Peter Psenak
Sent: Tuesday, July 25, 2023 6:11 PM
Bruno,
On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
Hi all,
IP reachability
,
R.
On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote:
Hi Robert,
On 25/07/2023 18:51, Robert Raszuk wrote:
> Hey Peter,
>
> I think the point Bruno is making is valid ... Imagine dual or
triple
> vendor networ
d networks (if ever to use UPA) this is NOT a
local decision,
For vast majority it is local as forwarding is using some sort of PE-PE
encapsulation.
Cheers,
R.
On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak
mailto:40cisco@dmarc.ietf.org>>
wrote:
Bruno,
On 25/07/2023 14
Bruno,
please see inline:
On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
Peter,
Thanks for your answer.
Please see inline [Bruno]
From: Peter Psenak
Sent: Tuesday, July 25, 2023 6:05 PM
Bruno,
On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
Hi all,
With RC5305
Bruno,
On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
Hi all,
IP reachability advertised by IS-IS is often used by other routing and
signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
such, UPA may affect those protocols.
Has UPA been presented in other WGs in the
Bruno,
On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
Hi all,
With RC5305, in IS-IS we can advertise two states for a prefix IP1:
* Positive reachability (state “1”), by advertising IP1 in TLV 135
with a metric lower than 0xFE00
* No reachability (state “0”) by either:
Hi Acee,
I am not aware of any undisclosed IPR.
thanks,
Peter
On 20/07/2023 01:19, Acee Lindem wrote:
Authors,
A cornucopia of IPR declarations have already been disclosed:
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-isis-fast-flooding
Are you aware of any
2023 at 12:47, Peter Psenak wrote:
Hi John,
please see inline (##PP):
On 27/06/2023 17:48, John Scudder wrote:
Hi Authors,
I don’t think we’ve completely closed on this. Zahed is asking for Section 3 to
be tightened a little bit. The authors haven’t either said “no we won’t” or
proposed text
Hi John,
please see inline (##PP):
On 27/06/2023 17:48, John Scudder wrote:
Hi Authors,
I don’t think we’ve completely closed on this. Zahed is asking for Section 3 to
be tightened a little bit. The authors haven’t either said “no we won’t” or
proposed text. In hopes of provoking some
John,
I'll remove the MUST.
thanks,
Peter
On 08/06/2023 15:05, John Scudder wrote:
Hi Peter and all,
On Jun 8, 2023, at 2:43 AM, Peter Psenak
wrote:
A node MUST participate in a Flex-Algorithm to be:
- Able to compute path for such Flex-Algorithm
- Part
Zahed,
please see inline:
On 08/06/2023 12:42, Zaheduzzaman Sarker wrote:
On Thu, Jun 8, 2023 at 9:36 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote:
Zahed,
please see inline:
On 08/06/2023 07:00, Zaheduzzaman Sarker via Datatracker wrote:
> Zaheduzzama
Hi Paul,
thanks for your comments, please see inline:
On 08/06/2023 03:55, Paul Wouters via Datatracker wrote:
Paul Wouters has entered the following ballot position for
draft-ietf-lsr-ip-flexalgo-13: No Objection
When responding, please keep the subject line intact and reply to all
email
Zahed,
please see inline:
On 08/06/2023 07:00, Zaheduzzaman Sarker via Datatracker wrote:
Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-lsr-ip-flexalgo-13: No Objection
When responding, please keep the subject line intact and reply to all
email addresses
Hi Robert,
On 05/06/2023 12:55, Robert Wilton via Datatracker wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ip-flexalgo-12: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines.
ne 1, 2023 at 06:19:54 PM GMT+3, Acee Lindem
wrote:
On Jun 1, 2023, at 06:54, Peter Psenak wrote:
Hi Antoine,
thanks for the review, please see my response inline:
On 01/06/2023 11:22, Antoine Fressancourt via Datatracker wrote:
Reviewer: Antoine Fressancourt
Review result: Re
Hi Antoine,
thanks for the review, please see my response inline:
On 01/06/2023 11:22, Antoine Fressancourt via Datatracker wrote:
Reviewer: Antoine Fressancourt
Review result: Ready
I have reviewed this document as part of the INT area directorate's ongoing
effort to review all IETF
Hi John,
I have uploaded the new version.
thanks,
Peter
On 19/05/2023 20:45, John Scudder wrote:
Hi Authors (and cc WG),
I see there were some changes that were agreed during IETF LC. It would be
great if you could issue a new version incorporating those before IESG
evaluation; in the
Yoav,
thanks for comments, please see inline:
On 15/05/2023 21:36, Yoav Nir via Datatracker wrote:
Reviewer: Yoav Nir
Review result: Has Nits
Hi.
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.
Hi Bill,
thanks for your comments, please see inline (##PP):
On 13/05/2023 22:38, Acee Lindem wrote:
Hi Bill,
Thanks for the Ops review. I reformatted your Email for readability and
continued discussion.
Thanks,
Acee
Reviewer: Qin Wu
Review result: Has Issues
I have reviewed this document
Hi Paul,
thanks for your comments, I fixed both of them.
Changes will be part of the next version.
thanks,
Peter
On 12/05/2023 16:21, Paul Kyzivat wrote:
[Resending with the the wg email address corrected]
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team
-authors of that
draft, could either you or Acee cover applicability for both IP Algo and
SRv6 Locator?
sure.
thanks,
Peter
That way we have functional parity for IP algorithm reachability for
OSPF all taken care of.
Thanks,
Ketan
On Thu, 4 May, 2023, 5:39 pm Peter Psenak, <mailto:p
a
revision with corrections if you want.
—John
On May 2, 2023, at 6:06 AM, Peter Psenak
wrote:
Hi John,
I apologize for the misses, likely the result of multiple editors
updating the draft in parallel.
I also fixed the nits and updated the security sections as you proposed.
Version 10 has been
’t insist on the proposed rewrite. But even if you
don’t use it you presumably should take the s/servers/serves/
proofreading correction.
I’m going to go ahead and request IETF Last Call, but feel free to
push a revision with corrections if you want.
—John
> On May 2, 20
(and Shraddha),
On Apr 28, 2023, at 9:13 AM, Peter Psenak
wrote:
Shradha and I have worked to address your comments.
The new version of the draft has been published.
Thanks for that. I’ve reviewed the diffs in 09. I’ve attached a short review of
it; there are some minor proofreading changes, but also
Hi John,
Shradha and I have worked to address your comments.
The new version of the draft has been published.
thanks,
Peter
On 20/04/2023 02:27, John Scudder wrote:
Hi Authors, WG,
Thanks for this spec and for your patience as it waited for me to review it.
I’ve supplied my questions and
Hi John,
I usually push txt version and give XML only to RFC Editors.
No particular reason, I can upload XML next time.
thanks,
Peter
On 20/04/2023 15:41, John Scudder wrote:
[adding individual cc for authors to work around bounce issues]
One additional request — when you post your next
uld answer directly.
It is a mutual respect and also be fair to all of us, as I tried to answer all
challenging questions whenever I could.
I thought I have answered all of them already during the discussion. Let
me try again, please see below.
Rgds
Louis
-Original Message-----
From: Pe
s
Louis
-Original Message-
From: Peter Psenak
Sent: Friday, April 14, 2023 7:03 PM
To: Weiqiang Cheng ; 'Peter Psenak'
; Louis Chan ; 'linchangwang'
; 'Les Ginsberg (ginsbe' ; 'Acee Lindem'
Cc: 'lsr' ; Krzysztof Szarkowicz
Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertis
that it may be optimized, does not mean it is a good idea to do so.
thanks,
Peter
B.R.
Weiqiang Cheng
-邮件原件-
发件人: Peter Psenak [mailto:ppse...@cisco.com]
发送时间: 2023年4月14日 19:03
收件人: Weiqiang Cheng; 'Peter Psenak'; 'Louis Chan'; 'linchangwang'; 'Les
Ginsberg (ginsbe'; 'Acee Lindem'
抄送: 'lsr
Peter Psenak
发送时间: 2023年4月14日 16:51
收件人: Louis Chan; linchangwang; 程伟强; Les Ginsberg (ginsbe; Acee Lindem
抄送: lsr; Krzysztof Szarkowicz
主题: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
forFlex-Algorithm
Louis,
On 14/04/2023 10:25, Louis Chan wrote:
Hi Peter,
I do not think we
s, but only 5% difference in order to achieve some desired
behavior. In this case, we should find a way to pack it efficiently.
maybe you need a new version of the protocol to do what you propose.
thanks,
Peter
Rgds
Louis
-Original Message-
From: Peter Psenak
Sent: Friday, April 14,
that is
advertised per link. You may have many SRLGs, many affinities, etc.
Peter
Rgds
Louis
-Original Message-
From: Peter Psenak
Sent: Thursday, April 13, 2023 5:09 PM
To: Louis Chan ; linchangwang ; 程伟强
; Les Ginsberg (ginsbe ; Acee Lindem
Cc: lsr ; Krzysztof Szarkowicz
Subject: Re
th offset would also reduce the refresh requirement.
Rgds
Louis
-Original Message-
From: Peter Psenak
Sent: Wednesday, April 12, 2023 11:26 PM
To: linchangwang ; 程伟强 ; Louis Chan
; Les Ginsberg (ginsbe ; Acee Lindem
Cc: lsr ; Krzysztof Szarkowicz
Subject: Re: [Lsr] IETF-116 LSR - IGP
algos.
thanks,
Peter
Rgds
Louis
*From:* Ketan Talaulikar
*Sent:* Thursday, April 13, 2023 1:44 PM
*To:* Louis Chan
*Cc:* Krzysztof Szarkowicz ; Robert Raszuk
; linchangwang ; Acee
Lindem ; Peter Psenak ; 程伟强
; Les Ginsberg (ginsbe
; lsr
*Subject:* Re: [Lsr] IETF-116 LSR - IGP
Robert Raszuk ,linchangwang
,Acee Lindem ,Peter Psenak ,"程伟强"
,"Les Ginsberg(ginsbe" ,lsr
*发送时间：*2023-04-13 12:31:12
*主题：*Re: [Lsr] IETF-
116 LSR - IGP extensions for Advertising OffsetforFlex-Algorithm
Hi Ketan,
Just a short response.
Krzysztof,
On 12/04/2023 17:50, Krzysztof Szarkowicz wrote:
Hi,
On 2023 -Apr-12, at 17:48, Peter Psenak wrote:
[External Email. Be cautious of content]
Krzysztof,
On 12/04/2023 17:41, Krzysztof Szarkowicz wrote:
Hi,
It is the question, if we could for example have more than 20 (e.g
guarantees, corresponding to different resource requirements.
__ __
Thanks,
Changwang lin
__ __
*From:*Acee Lindem [mailto:acee.i...@gmail.com
<mailto:acee.i...@gmail.com>]
*Sent:* Wednesday, April 12, 2023 10:12 PM
*To:* Peter Psenak
*Cc:* l
,
Changwang lin
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Wednesday, April 12, 2023 7:10 PM
To: 程伟强; Louis Chan; Les Ginsberg (ginsbe; Acee Lindem
Cc: lsr; Krzysztof Szarkowicz
Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising
,
Changwang lin
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Wednesday, April 12, 2023 7:10 PM
To: 程伟强; Louis Chan; Les Ginsberg (ginsbe; Acee Lindem
Cc: lsr; Krzysztof Szarkowicz
Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising
Weiqiang,
please see inline (##PP):
On 12/04/2023 12:05, 程伟强 wrote:
Hi Louis and Les,
My two cents from operator perspective.
We've met the same problem when applying Flex Algo in SRv6 network.
what problem exactly, can you please describe it?
As the number of slices and the scale of
On 29/03/2023 10:29, Les Ginsberg (ginsberg) wrote:
a)Big TLV does not provide what the draft claims it does
b)Having two ways to do the same thing is undesirable
I can only agree with the above, (b) being the most important.
Peter
___
Lsr mailing
On 28/03/2023 11:41, Aijun Wang wrote:
There is already overload bit to accomplish the maintenance purposes,
Why do you guys repeat such work again?
OL-bit is only propagated inside the area. We are solving
inter-area/inter-domain routing convergence here.
Peter
Aijun Wang
China
Mar 27, 2023 at 8:07 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote:
Robert,
On 27/03/2023 16:57, Robert Raszuk wrote:
> Hi Peter,
>
> > 4. Is an UPA for a /24 equivalent to 255 UPA for /32?
(i.e. will
> &
Robert,
On 27/03/2023 16:57, Robert Raszuk wrote:
Hi Peter,
> 4. Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will
> trigger BGP PIC edge for 255 /32)
no. For BGP PIC to be triggered by UPA, the UPA must be sent for the
prefix that is used to resolve BGP
Hi Bruno,
On 27/03/2023 06:59, bruno.decra...@orange.com wrote:
Hi authors,
Please find below some questions.
1. Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises
IP1 with MAX metric. Is this prefix reachable or unreachable (or both)?
UPA is meant to be sent only for
Hi Robert,
On 27/03/2023 10:05, Robert Raszuk wrote:
Hi,
I would like to get more clarification in respect to extending External
LSAs for UPA. Area summary use case is pretty clear - but in case of
redistribution (typical src of external LSAs) IMO we are going way too
far with this. Let's
Hi Acee,
I'm not aware of any undisclosed IPRs related to this draft.
thanks,
Peter
On 10/03/2023 14:43, Acee Lindem wrote:
Co-Authors,
Are you aware of any IPR that applies to
draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01?
If so, has this IPR been disclosed in compliance with IETF
Acee,
if you ask me, I would not do anything. "IS" is correct in the text and
it's well known.
my 2c,
Peter
On 05/03/2023 14:32, Acee Lindem wrote:
Hi Tony,
On Mar 4, 2023, at 4:42 PM, Tony Li wrote:
Hi all,
IMHO, this erratum is correct, but the proposed fix is incorrect.
In this
Hi Acee,
I am not aware of any undisclosed IPR.
thanks,
Peter
On 22/02/2023 22:45, Acee Lindem wrote:
Co-Authors,
Are you aware of any IPR that applies to draft-ietf-lsr-dynamic-flooding-11.txt?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669
Hi Acee,
On 15/12/2022 14:45, Acee Lindem wrote:
Hi Peter,
On Dec 15, 2022, at 8:11 AM, Peter Psenak
wrote:
On 15/12/2022 13:51, John Scudder wrote:
Thanks, Peter.
Doesn’t this mean that the OSPFv3 draft needs to create its own registry for
the flags, then?
it does.
Section 2 defines
.
On Dec 15, 2022, at 6:29 AM, Peter Psenak wrote:
John,
On 14/12/2022 22:59, John Scudder wrote:
Hi Authors, WG,
As part of my review of draft-ietf-idr-bgpls-srv6-ext-12 I was looking at these
documents and came up with a few comments that would otherwise become part of
my AD review
John,
On 14/12/2022 22:59, John Scudder wrote:
Hi Authors, WG,
As part of my review of draft-ietf-idr-bgpls-srv6-ext-12 I was looking at these
documents and came up with a few comments that would otherwise become part of
my AD review for ospfv3-srv6-extensions, so I thought I’d share them
Chris,
I am not aware of any IPR related to this draft.
Peter
On 07/12/2022 14:20, Christian Hopps wrote:
This begins a 2 week WG Last Call, ending Dec 21, 2022, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/
Authors,
Please indicate to the list, your knowledge of
Chris,
I am not aware of any IPR related to this draft.
Peter
On 07/12/2022 14:20, Christian Hopps wrote:
This begins a 2 week WG Last Call, ending Dec 21, 2022, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/
Authors,
Please indicate to the list, your knowledge of
On 12/11/2022 06:45, Christian Hopps wrote:
On Nov 9, 2022, at 2:13 PM, Peter Psenak
wrote:
On 09/11/2022 14:56, David Lamparter wrote:
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
I guess I'd like to understand what one would accomplish with further
specification
On 10/11/2022 11:59, Acee Lindem (acee) wrote:
Hi Robert,
*From: *Robert Raszuk
*Date: *Thursday, November 10, 2022 at 10:51 AM
*To: *Acee Lindem
*Cc: *Peter Psenak , Bruno Decraene
, David Lamparter ,
"lsr@ietf.org"
*Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-anno
On 09/11/2022 22:51, Aijun Wang wrote:
Hi, Peter:
Actually, the “unreachable” meaning of LSInfinity in current standard is
not the same as the “unreachable” meaning that we are supposed to act:
1) In current standard, the “unreachable” is meant that the related
prefix will not be in the
Bruno,
On 10/11/2022 02:18, bruno.decra...@orange.com wrote:
Peter,
From: Peter Psenak
Sent: Wednesday, November 9, 2022 2:13 PM
On 09/11/2022 14:56, David Lamparter wrote:
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
I guess I'd like to understand what one would
On 09/11/2022 16:32, David Lamparter wrote:
On Wed, Nov 09, 2022 at 03:16:11PM +, Peter Psenak wrote:
On 09/11/2022 15:48, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
as far as that /128 is not used as BGP next-hop (which obviously is not
the case
1 - 100 of 726 matches
Mail list logo
