Reviewer: Linda Dunbar
Review result: Ready
I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs
IANA action state changed to "In Progress"
Datatracker URL:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
The IESG has approved the following document:
- 'IGP extension for PCEP security capability support in PCE discovery'
(draft-ietf-lsr-pce-discovery-security-support-13.txt) as Proposed Standard
This document is the product of the Link State Routing Working Group.
The IESG contact persons are
Note that for LSR, we usually do this anyway so this really isn’t a change of
policy. At least as a document shepherd, I always try and remember.
Thanks,
Acee
From: Andrew Alston - IETF
Date: Wednesday, October 12, 2022 at 3:30 AM
To: "rtg-cha...@ietf.org"
Subject: Directorate Early Reviews
IESG state changed:
New State: Approved-announcement to be sent
(The previous state was IESG Evaluation::AD Followup)
Datatracker URL:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/
___
Lsr mailing list
One correction:
“It should be expanded further” should be “it shouldn’t be expanded further”
Aijun Wang
China Telecom
> On Oct 13, 2022, at 18:53, Aijun Wang wrote:
>
> Hi, Acee and Peter:
>
> I think you all misunderstood the intent of his scenario.
> The correct understanding are the
Hi, Acee and Peter:
I think you all misunderstood the intent of his scenario.
The correct understanding are the followings:
1) When aggregate route is configured in the ABR, the specified detail route
should be withdrawn.
2) ABR can withdraw the advertised LSA that describes the specific detail
Hi Dhruv,
Sorry for being slow. Yes, these changes look fine. Thanks for accommodating
my concerns. I’ve cleared my discuss.
Regards,
Rob
From: iesg On Behalf Of Dhruv Dhody
Sent: 05 October 2022 14:03
To: Rob Wilton (rwilton)
Cc: The IESG ;
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-pce-discovery-security-support-13: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph,
Hi Zhibo,
On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo" wrote:
Hi LSR:
LSInfinity
The metric value indicating that the destination described by an
LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
I want to clarify the meaning of unreachable in LSifinity,
Zhibo,
On 13/10/2022 08:26, Huzhibo wrote:
Hi LSR:
LSInfinity
The metric value indicating that the destination described by an
LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
I want to clarify the meaning of unreachable in LSifinity,
Assume that a node advertise specific route
Acee:
The reason that the operator set the metric to one large enough value, is to
let the associated route be the non-optimal selection, not let its unreachable.
Because there are normally several links away from the ABR to the advertised
router which is connected directly the prefix that has
And, in https://www.rfc-editor.org/rfc/rfc2328.html#page-135 (Section
12.4.3. Summary-LSAs), it states clearly:
"If a router advertises a summary-LSA for a destination which
then becomes unreachable, the router must then flush the LSA
from the routing domain by setting its
Hi LSR:
LSInfinity
The metric value indicating that the destination described by an
LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
I want to clarify the meaning of unreachable in LSifinity,
Assume that a node advertise specific route of 1.1.1.1/32, and an aggregate
route
14 matches
Mail list logo
