Hi Cheng, See responses inline.
> On Sep 11, 2025, at 10:04 AM, Cheng Li via Datatracker <[email protected]> > wrote: > > Document: draft-ietf-lsr-ospf-ls-link-infinity > Title: Advertising Unreachable Links in OSPF > Reviewer: Cheng Li > Review result: Has Issues > > Hi Authors, > > I have reviewed the draft. Basically, It is easy to read, but you might need > to > clarify some details. Please see below for more details. > > Thanks, > Cheng > > Abstract > 1.[Cheng] Which may refer to the whole sentence instead of the links. suggest > OLD: > In certain scenarios, it is necessary to advertise unreachable links in OSPF, > which should be explicitly excluded from the related SPF calculation. NEW： In > certain scenarios, it is necessary to advertise unreachable links in OSPF, so > that the links can be explicitly excluded from the related SPF calculation. I rewrote this in a different way. > > 2. [Cheng]You may not need to add the reference in the abstract, so suggest to > remove the RFCXXXX in the abstract. You can add the reference in the > introduction section. > > S/Stub Router Advertisement (RFC 6987)/Stub Router Advertisement No - it is fine to refer to other RFCs in the abstract as long as you don't use an RFC reference. > 3. [Cheng]you might rephrase the logic of the second paragraph, for example. > move "This document updates RFC 6987 and RFC 8770." to the end of this > paragraph. Ok. > > Introduction > [Cheng]1. The introduction is quite short. Suggest to add move to explain > 1.1. what kind of typical scenarios you mean when saying in 'specific' > scenarios. 1.2. please clarify traffic engineering purposes and hop-by-hop > routing. I do not understand thess two terms clearly, hope to have more info. > 1.3. included in a Flexible Algorithm? why a link can be included in a > Flexible > Algorithm? You may mean the topology associated with the Flexi algo? > > 2. [Cheng]s/there is a requirement/it is needed > 3. which MUST NOT be considered during > [Cheng]In the abstract section, should is used, but here, you change to use > MUST NOT. Please clarify this point. [Cheng]s/his/This 4.[Cheng] it may be > better to say, this document specifies a method of using xxx. This has been rewritten. The use cases are in section 2 and will not be added to the introduction. > > section 2 use cases. > 1 There is a link available for Traffic Engineering. > [Cheng]Please clarify what is TE. You may mean an explicit forwarding path > using Adj-SIDs? may use explicit routing? 2. [Cheng]please clafify > best-effort. > You may mean, loose path or loose forwarding? 3. [Cheng]I do not understand > the > logic of " If this link is included in the SPF calculations, best-effort > traffic may be routed over the link." > > [Cheng]is the link not availble or not allowed for BE traffic? are you talking > about this link is not reachable in SPF calculation, but it can be used in > explicit routing? I rewrote this. > > 4. Flex-Algorithm allows OSPF to compute the paths along the constrained > topology. > > [Cheng]I can see your point, but Flex-Algo allows OSPF, since not that > correct. > suggest to rephrase the logic. OSPF does install routes based on the Flex-Algo constraints so I don't see why you say it is incorrect. > > 5. The topology used by Flex- Algorithm 128 is shown in Figure 3. > > [Cheng]I may be wrong. In my understanding, the relation should be > 'associated'? not 'used by'? > > 6. Flex-Algorithm 128 is used for routing particular flows, such as those for > specific traffic. > > [Cheng]it is not clear here. Flex-algo is used for calculating a constrained > tologogy? and what is the meaning of 'such as those for specific traffic.' > > 7. The "Red" links used by Flex-Algorithm 128 are sub-interfaces with > dedicated > queues for guaranteed bandwidth. > > [Cheng]again, 'used by' may not be correct. Suggest to review the verbs in > this > document. > > 8. Sub-interfaces in other traffic and default topology are omitted from the > example figure for clarity. [Cheng]suggest to clarify 'Sub-interfaces in other > traffic'. you may delete 'traffic and' [Cheng]s/default topology/the default > topology > > 9. > [Cheng] s/So, it is expected/Therefore, it is expected > > 10. However, these links are also contained in the default topology computed > by > the normal SPF calculation, and these links may also be used for best-effort > traffic. Therefore, it is a problem that the dedicated links for > Flex-Algorithm > are still reachable in base SPF calculation. [Cheng]what do you mean normal > SPF > and base SPF here, any different. I actually can understand. But suggest to > double check the sync up the correct wording. > > 11. > This allows Flex-Algorithm 128 to route only specific traffic on the "Red" > links. > > [Cheng] suggest to rephrase 'this allows FA 128 to route' I simplify the use case to avoid the rat holes you're trying to take us down. > > Section 3 > > 1. This document specifies that if the IGP metric of a link is advertised as > LSLinkInfinity (0xffff), it MUST NOT be considered during the related SPF > computation. > > [Cheng] S/specifies that if the IGP/specifies a mechanism that when the IGP No. It is clear without the indirection. > > s/it MUST NOT/the link MUST NOT > > I do not understand 'the related SPF computation.', suggest to explain > 'related' Although I believe it is clear, I changed it to "associated". > > 2. LSLinkInfinity is specified. > > [Cheng]I do not understand， what is the meaning of 'Specified? ' It means that LSLinkInfinity is advertised as the value of the IGP metric. This is the whole point of draft. How can you not understand "specifying" LSInfinity and suggest "specifying a mechanism" above? > > 3.s/The Router-LSA [RFC2328] and [RFC5340]/The Router-LSA [RFC2328][RFC5340] Ok. > > 4.Prior to this specification, OSPF treated links advertised as LSLinkInfinity > as reachable [RFC2328] > > [Cheng]Suggest to rephrase it. > > As defined in [RFC2328], links that advertised as LSLinkInfinity are treated > as > reachable in OSPF protocol. No - I think the existing is clear. > > Section 4. > > 1. Support of the Unreachable Link support capability SHOULD be configurable. > > [Cheng]It is not clear to me in grammer. Might need to double check or > rephrase > the wording. It is fine the way it and if you read other IGP drafts, you'll fine similar phrasing. > > skip setcion 5, because we do have a YANG doctor. > > Section6. > > 1. Causing routing loop might be treated as a security issue? If yes, then > suggest to add text to describe it in this section. No - the specified backward compatibility mechanisms prevent routing loops. Thanks, Acee > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
