Hi John, >>> @@ -302,14 +315,23 @@ >>> value of the SRGB advertised by all Inside Nodes MUST start at the >>> same value. The range advertised for the area will be the minimum of >>> all Inside Nodes. >>> ++--- >>> +jgs: shouldn't the document say something about what to do if >>> +either one of the MUST requirements isn't met? >>> ++--- >> >> >> If either is not met, it would be a protocol error and major malfunctions >> will occur. >> The network manager should remedy the problem. I’m not sure that needs to be >> called out. >> >> If you’re suggesting that implementations should complain if those >> constraints are >> not met, we did not specify that as that would require a walk through the >> LSDB >> that is not otherwise required. > > Doesn't the area leader already have to do an operation like that, to > determine what range to advertise? I had expected to be told what the area > leader is supposed to do if it encounters non-overlapping SRGB as it looks > for the minimum mentioned in the quoted text. Halt and catch fire? Give up > and log an error? Something else?
Not strictly, as one can cheat. However, that’s probably cheating a bit too much. I will add text suggesting logging and giving up. > (Also, now that I've looked at that sentence a few more times, a nit: how > about "will be the minimum of that advertised by all Inside Nodes"?) Sure. >>> @@ -644,6 +701,28 @@ >>> If the inside area supports Traffic Engineering (TE), the Area Leader >>> SHOULD copy TE related sub-TLVs [RFC5305] Section 3 to each Extended >>> IS Reachability TLV in the Proxy LSP. >>> ++--- >>> +jgs: what is 4.4.4 and 4.4.5 are specified as MAY. According to the RFC >>> +2119 definition of MAY, >>> + >>> +5. MAY This word, or the adjective "OPTIONAL", mean that an item is >>> + truly optional. >>> + [etc] >>> + >>> +That means it would be considered completely reasonable and OK for >>> +the area leader to omit both the IS neighbors TLV and end the extended >>> +IS neighbors TLV. Would the protocol still function correctly and >>> +usefully if both of those TLVs were omitted from the Proxy LSP? Seems >>> +as though it wouldn't. >>> + >>> +I think probably what is going on here is that you're trying to say >>> +that ordinarily, only one or the other would be expected, not both. >>> +The RFC 2119 keywords seem like a poor fit for expressing this. This >>> +seems like a good time to remind you that it's not mandatory to use >>> +RFC 2119 keywords, and in cases like these where they hinder, >>> +rather than help, clarity, it's worth considering whether you should >>> +rewrite the affected text without relying on them. >>> ++--- >> >> >> Yes, we would expect one and not both. There’s a sentence that even says >> that. > > You're referring to this sentence, right? "An entry for a neighbor in both > the IS Neighbors TLV and the Extended IS Neighbors would be functionally > redundant, so the Area Leader SHOULD NOT do this." Exactly >> We intentionally selected 2119 keywords because we wanted to explicitly >> say what is permissible. >> >> Again, the protocol would work syntactically and semantically if things are >> omitted, but not meet network architectural requirements. Additionally, >> we did not want to preclude filtering, so we did not think that ‘MUST’ was >> called >> for. > > I could swallow your justification for the various SHOULDs because you said > (my paraphrase) that there isn't any single one of them that's of the essence > for the utility of the protocol. However, if you don't advertise either of > the IS Neighbors or Extended IS Neighbors TLVs, I don't think you have a > useful routing protocol, do you? So, even though neither one of them, > individually, is of the essence, collectively they still are. I don't think > your text captures this. An example of text that would address this concern > is, > > OLD: > An entry for a neighbor in both the IS Neighbors TLV and the Extended > IS Neighbors would be functionally redundant, so the Area Leader > SHOULD NOT do this. > > NEW: > An entry for a neighbor in both the IS Neighbors TLV and the Extended > IS Neighbors would be functionally redundant, so the Area Leader > SHOULD NOT do this. Although considered in isolation, either of these > two TLV types may be omitted, at least one MUST be included. > > That's only an illustration, I don't think it's the most artful way to do it. > My own preference would be something more like, change both MAY to “can”, and > add something like, > > The Area Leader MAY omit either the IS Neighbors TLV or the Extended > IS Neighbors TLV, but it MUST include at least one of them. > > If you're stuck on having each subsection stand on its own, you’d put the > sentence in twice, once each. But I think you aren't stuck on that, because > you only include the "functionally redundant" paragraph I have quoted once. I can live with your proposal. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
