Skip to main content

An MPLS-Based Forwarding Plane for Service Function Chaining
RFC 8595

Yes

(Deborah Brungard)
(Ignas Bagdonas)

No Objection

(Adam Roach)
(Ben Campbell)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 05 and is now closed.

Alvaro Retana No Objection

Comment (2019-03-04 for -05)
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.

Warren Kumari No Objection

Comment (2019-03-05 for -05)
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.

(Deborah Brungard; former steering group member) Yes

Yes (for -05)

                            

(Ignas Bagdonas; former steering group member) Yes

Yes (for -05)

                            

(Martin Vigoureux; former steering group member) Yes

Yes (2019-03-06 for -05)
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./

(Adam Roach; former steering group member) No Objection

No Objection (for -05)

                            

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection (2019-03-07 for -06)
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.)

(Ben Campbell; former steering group member) No Objection

No Objection (for -05)

                            

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2019-03-07)
Thank you for resolving my DISCUSS points!

(Eric Rescorla; former steering group member) (was Discuss) No Objection

No Objection (2019-03-09)
I have discussed appropriate text with the editors that will resolve my DISCUSS and trust them to submit a new draft.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2019-03-06 for -05)
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).

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -05)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -05)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -05)