Subject: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 30 Oct 2016 16:19:08 -0000

Hi Bess WG,

We made some updates to this document to tidy it and to get the terminology in line with RFC 7665.

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 30 October 2016 16:09
> To: Eric Rosen; Adrian Farrel; John Drake; Jim Uttaro; Luay Jalil
> Subject: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-
> 01.txt
> 
> 
> A new version of I-D, draft-mackie-bess-nsh-bgp-control-plane-01.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
> 
> Name:		draft-mackie-bess-nsh-bgp-control-plane
> Revision:	01
> Title:		BGP Control Plane for NSH SFC
> Document date:	2016-10-30
> Group:		Individual Submission
> Pages:		37
> URL:            https://www.ietf.org/internet-drafts/draft-mackie-bess-nsh-bgp-
> control-plane-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-
> plane/
> Htmlized:       https://tools.ietf.org/html/draft-mackie-bess-nsh-bgp-control-
> plane-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-mackie-bess-nsh-bgp-control-
> plane-01
> 
> Abstract:
>    This document describes the use of BGP as a control plane for
>    networks that support Service Function Chaining (SFC).  The document
>    introduces a new BGP address family called the SFC AFI/SAFI with two
>    route types.  One route type is originated by a node to advertise
>    that it hosts a particular instance of a specified service function.
>    This route type also provides "instructions" on how to send a packet
>    to the hosting node in a way that indicates that the service function
>    has to be applied to the packet.  The other route type is used by a
>    Controller to advertise the paths of "chains" of service functions,
>    and to give a unique designator to each such path so that they can be
>    used in conjunction with the Network Service Header.
> 
>    This document adopts the SFC architecture described in RFC 7665.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 30 Oct 2016 13:00:37 -0400

Thank you authors.

Reading through this, I have a few questions.

1) I like the idea of being able to support multiple SFC overlays.  I 
can see circumstances when this would be valuable.  However, I can not 
see how it works.  (I presume I am missing something obvious.) If the 
SPI are unique, then sure, it works, but they are not really separate 
overlays.  They are merely administrative slices of the same overlay. 
The text in section 5 bullet 1 starts with observing that the path state 
is RT specific.  That part is fine.  It then asserts that the SFF that 
receives a packet can somehow tell which RT the packet goes with.  How? 
Since the unerlay is not partitioned into RTs (only the overlay) the 
transport mechanism does not indicate that.  And the data packet does 
not carry an RT.

2) The Path hop information (for a specific SPI, SI) allows for carrying 
multiple SFTs.  It allows for multiple SFIs, which is important and 
useful.  The multiple SFTs seems to be intended to allow for the case 
where SFT A or B can be done at hops 9 or 8.  Which would be nice to 
allow.  But since the second SFF (at hop 8) will not know whether the 
first SFF (at hop 9) chose A or B, I do not see how it can correctly 
choose the opposite.  Are there additional assumptions made to enable 
this?  The text in the example of section 8.4 seems to imply a different 
sort of use case for this multiple SFT at a hop situation.  But I can 
not see how that will be implemented interoperably.  Having control know 
magically that the SFF can correctly select an SFT based on unspecified 
information seems problematic.

3) I am a bit confused by section 6.1 on looping, jumping, and 
branching.  Looping (more accurately spiraling) should not require any 
special handling.  Simply put the same SFI information at two different 
SIs in the same SPI, and spiraling occurs.  No special handling needed. 
Jumping seems to be a special case of reclassificaiton.  So I would 
prefer to see it simply handled by the same mechanism (why have two 
mechanisms that can do the same job.)  Branching seems not to handle the 
most common case where we need to branch.  That is the situation where 
packets in a given SFP, as a result of processing by an SF, will usually 
continue down the SFP, but under some circumstances (and there are a 
range of them) will need to take a different path.  The Assumption in 
the SFC work is that the SF indicates the need for reclassificiation by 
adjusting the flags in the NSH header, and that a classifier co-resident 
with the SFF then performs reclassification.  The mechanism you describe 
in section 6.1 does not seem to support that.
3') Also, that is why we do not usually describe the classifier as a 
service function.  Classifiers (including in path reclassifiers) are 
permitted to overwrite the SFP ID.  Service functions are not permitted 
to do that.

4) I notice that the examples still show the SI being adjusted by more 
than 1.  The NSH draft has been clarified, at the request of the AD and 
WG, to make it clear that the SI is decremented by 1 at each hop.  (If 
that were not the case, we would need additional information in the 
control as to how much to decrement the SI.  Which would be a 
complication with no value.)

Yours,
Joel