[Last-Call] Re: [Lsr] Re: draft-ietf-lsr-igp-ureach-prefix-announce-08 ietf last call Genart review

["Aijun Wang" <wangaijun@xxxxxxxxxxxxxxx>]

I  agree with that  “Not advertising reachability (0) is different from advertising unreachability (-1).”

The document has another similar paradox-----Not advertising unreachability(0), is SAME as the reachability(1)----Actually, they are also DIFFERENT.

For brevity, I removed the unrelated discussions in the previous mail.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: forwardingalgorithm@xxxxxxxx [mailto:forwardingalgorithm@xxxxxxxx] On Behalf Of bruno.decraene@xxxxxxxxxx
Sent: Monday, June 30, 2025 8:04 PM
To: Peter Psenak <ppsenak=40cisco.com@xxxxxxxxxxxxxx>; Dale Worley <worley@xxxxxxxxxxx>; spring-chairs <spring-chairs@xxxxxxxx>; Yingzhen Qu <yingzhen.ietf@xxxxxxxxx>
Cc: draft-ietf-lsr-igp-ureach-prefix-announce.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx; gen-art@xxxxxxxx
Subject: [Last-Call] Re: [Lsr] Re: draft-ietf-lsr-igp-ureach-prefix-announce-08 ietf last call Genart review

 

Peter, Dale,

 

Please see inline [Bruno]

 

From: Peter Psenak <ppsenak=40cisco.com@xxxxxxxxxxxxxx>
Sent: Thursday, June 26, 2025 5:04 PM
To: Dale Worley <worley@xxxxxxxxxxx>; gen-art@xxxxxxxx
Cc: draft-ietf-lsr-igp-ureach-prefix-announce.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
Subject: [Lsr] Re: draft-ietf-lsr-igp-ureach-prefix-announce-08 ietf last call Genart review

 

Hi Dale,

 

thank you for your comments, please see responses inline (look for ##PP):

 

I have updated the draft and attached the diffs.

 

On 24/06/2025 19:57, Dale Worley via Datatracker wrote:

Document: draft-ietf-lsr-igp-ureach-prefix-announce

Title: IGP Unreachable Prefix Announcement

Reviewer: Dale Worley

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.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document:  draft-ietf-lsr-igp-ureach-prefix-announce-08

Reviewer:  Dale R. Worley

Review Date:  2025-06-24

IETF LC End Date:  2025-06-24

IESG Telechat date:  [not known]

Summary:

    This draft is on the right track but has open issues, described in

    the review.

As far as I can tell, the proposed mechanism is sound as a solution to

the stated problem.  But I am not a routing expert.  However, the

document needs improved organization as an exposition of the

mechanism.  It seems like the current version would be sufficient for

a routing expert to implement the mechanism but it lacks the clarity

needed for either a standards definition or for non-expert readers.

##PP
I appreciate your effort to make the document more readable for the non-experts,
but I'm afraid, some level of routing expertise would still be required from the reader.
We are building on existing RFCs and a familiarity with those is  expected. But I'll try
to make easier to read.

Major issues:

It would help if the earlier parts of the document (that is, sections

1 and 2, before the specifics of IS-IS and OSPF usage are introduced)

explained the mechanism conceptually.  In particular, it would be

helpful to have a direct statement of the significance of the U and UP

bits, independent of how the bits are implemented in each routing

protocol.  E.g.

    A UPA announcement is indicated by attaching the U bit to the

    announcement of a prefix, which thus indicates that the prefix is

    unreachable.  A UPA may also have the UP bit attached, indicating that

    the unreachability is due to a planned event.  How the U and UP bits

    are attached to a prefix is dependent on the routing protocol and is

    described later.

##PP:

This document does NOT define how to advertise prefix unreachability. 

That has been defined long time back in RFC5305, RFC2328, and RFC5340.

[Bruno] That is not the case for IS-IS [RFC5305]. IS-IS has no existing procedure to advertise negative reachability (aka advertising unreachability).

It has procedure for:

-        Advertising reachabilty (by advertising the prefix in Extended IP Reachability TLV with a metric below 0xFE000000) 

-        Not advertising reachability (by either not advertising the prefix or by advertising a metric larger than MAX_PATH_METRIC (0xFE000000)

Not advertising reachability (0) is different from advertising unreachability (-1).

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx