Ballot for draft-ietf-mpls-sfc
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Apologies, I intended to finish reviewing this, but ran out of time (and have an early flight tomorrow). What I read all seemed fine, and I'm balloting NoObj. I do have 2 tiny nits: Abstract: "Actions may include swapping or popping the labels as well, as using the labels" -- the comma seems superfluous / wrong. I think perhaps "NSH MUST NOT assign SPI values greater than (1048575) 2^20 - 1 or less than 16." -- I'm concerned that people might be lazy and not everyone can do 2^20 -1 in their head.
Hello thank you for this document. I know I'm being too pernickety: You say: o An SFF MUST decrement the TTL by one each time it performs a forwarding lookup. but in the examples you also say: b. When the packet arrives at SFFa it strips any labels associated with the tunnel that runs from the classifier to SFFa. SFFa examines the top labels and matches the SPI/SI to identify that the packet should be forwarded to SFa. The packet is forwarded to SFa unmodified. and d. SFFa modifies the SI in the lower label stack entry (to 254) and uses the SPI/SI to look up the forwarding instructions. It could look as two forwarding lookup, which, according to the requirement, could lead to two TTL decrements. I do read in step b that the packet is forwarded unmodified, and read in Section 6 "The TTL in SF label stack entry is decremented once for each forwarding hop in the SFP" but still I wonder if some clarification wouldn't be beneficial. nits: TTL: The TTL fields in the SFC Context label stack entry SF label stack entry SHOULD be set to 1 as stated in Section 5, Do you mean: SFC Context label stack entry *and* SF label stack entry ? s/document)./document./
Thanks for addressing my DISCUSS. Original COMMENT below. = Section 4.5 = OLD The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but has since been moved out of those documents. NEW The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted. (I think this is about the ideas, not the organization of documents.)
Thank you for a very clear document! I think that the only NSH functionality not included in this document is the O bit (OAM packet). I know that, even in rfc8300, the operation (beyond setting the bit) is not defined...and that work is still in progress in the SFC WG. However, given that this document describes a "logical representation of the NSH", I think it is necessary to point out why the coverage is not complete. In looking through the mail archive, I like the thoughts posted by one of the authors [1] and would like to see something like that reflected in the document. [1] https://mailarchive.ietf.org/arch/msg/mpls/b9Duw-9ShdCrIRyis3TOJWw-_pw nits: s/(as described in Section 4.1/(as described in Section 4.1) s/(see [I-D.ietf-bess-nsh-bgp-control-plane]/(see [I-D.ietf-bess-nsh-bgp-control-plane]) s/TC: The TC bits have no meaning./TC: The TC bits have no meaning in this case. s/to determine to which SFF or instance of an SF (an SFI) to deliver the packet./to determine which SFF or instance of an SF (an SFI) to deliver the packet to.
Thank you for resolving my DISCUSS points!
I have discussed appropriate text with the editors that will resolve my DISCUSS and trust them to submit a new draft.
One minor editorial comment: The abstract is quite long (compared to usual RFC abstracts). I recommend to only have the last paragraph (or a slightly extended version of the last paragraph).