Hi Samuel,
This is all looking very good. Thanks for the work. Following up on a few small points. Cheers, Adrian >> 3.5 >> >> You describe the requirement that if path a shows an opposite direction >> relationship with path b. >> >> But (presumably) there is the possibility of setting up paths one at a >> time. How does that work? > > <S> Do you mean in case of opposite paths associated within single LSP? If yes, > then I would expect them to be always signalled atomically - I can add text to mnake it clear: > > Typically, the referenced path is in the same PCEP LSP, where > forward paths (R-flag=0) and reverse paths (R-flag=1) are > signaled together in a single PCEP message. This allows bidirectional > path relationships to be established atomically within one LSP. > Alternatively, the referenced path may be in an associated > opposite-direction LSP (using the ASSOCIATION object per RFC 9059). Yes, it is the case of an association that bothers me. Signal forward path without a reverse path. Signal reverse path with association to forward path. But forward path does not yet have association to reverse path. Agree that this situation will resolve (forward path is resignaled), but there is a window that appears to be a failure case. But this all goes away with. >> 3.5 >> >> I wondered, given that the draft rules out using the backup processing >> for p2p paths, whether you should rule out using the reverse path >> association for p2mp paths. It is certainly the case that p2mp reverse >> path is a complex issue. >> >> <S> I'm fine with that. P2MP draft can still define it if needed. You appear to be saying: * P2P reverse paths not in scope for this document because P2P is out of scope * P2MP reverse path is deferred to P2MP draft if needed So reverse path is struck from this document? >> 3.6.1 >> >> Is there any guidance about the value of the FC field? Is it >> >> <S> Is the comment complete? I can imagine extending definition of FC field for >> example with following text (but I'm not sure if you are really looking for that or >> something else): >> >> The FC field allows up to 8 different forward classes >> (values 0-7). The semantics of specific FC values are locally >> significant and determined by local policy or configuration. Ah, sorry about that. Must have become distracted. You have almost completely answered the point. Be careful about "local" - do you mean per link, per node, per subnet, per PCE domain, per operator, . ? If the scope is wider than a node, how are policies kept consistent across multiple nodes? (You may be able to punt this "Operational Considerations") >> 6. >> >> I believe your examples should use addresses from the ranges reserved >> for documentation. That is 2001:db8::/32 and 3fff::/20 >> >> <S> Are you referring to "100:1.1.1.1" and "100:2.2.2.2"? If yes, then I assume that we need >> to replace them with blocks from "https://datatracker.ietf.org/doc/html/rfc5737#section-3"; >> since those are just combinations of originator ASN (100) and IPv4 addresses. Hmmm. I assumed that in this context "originator" was supposed to be an IPv6 address. But, I should have looked at RFC 9256 (which you did reference!) and specifically section 2.4 There we have: Autonomous System Number (ASN): represented as a 4-byte number. If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and the high-order bits MUST be set to 0. Node Address: represented as a 128-bit value. IPv4 addresses MUST be encoded in the lowest 32 bits, and the high-order bits MUST be set to 0. So, I suspect your encoding with a colon is a convenience (as shown in 2.13 of 9256) and I won't push against that now (should have caught it when reviewing 9256 before it was published) And that leaves us with: 1. This example is not trying to use an IPv6 address 2. The example should use documentation addresses from the IPv4 space (as you noted above) 3. There would, ideally, be an example using IPv6 addresses (I mean, SRv6 not SRv4 ;-) 4. The encoding using a colon is going to be very confusing when you use an IPv6 address >> 6.1 >> >> Consider the following sample SR Policy, taken from >> [RFC9256]. >> >> I don't find that sample in 9256. >> >> <S> I assume that it was originally referring to: >> https://www.rfc-editor.org/rfc/rfc9256#section-2.13 >> But I can just simplify to "Consider the following sample SR Policy". You probably have the best solution. Fixing up the addresses would work as well. >> The inclusion of the Implementation Status section is appreciated >> (although it is pretty thin). Obviously, the early assignments done by >> IANA has made this a lot easier. Given that there are some code points >> still marked as TBDx, I wonder how the "full" implementations have been >> achieved. > > <S> Ack, I'm not sure about that part. I'll keep authors/contributors from Ciena to comment. > Otherwise I can just update it to "Partial". Yeah. Of course, the cynic in me says "Partial? Which parts?"
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
