Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt

["Andrew G. Malis" <[e-mail]>]

Jim,

Thanks. To paraphrase what I just said to Joel, if that’s the intent, then
the text should make it clear.

Thanks,
Andy


On Thu, Apr 28, 2016 at 9:22 AM, Jim Guichard (jguichar) <[e-mail]
> wrote:

> Hi Andy,
>
> I think the key point is that NSH != network overlay but rather utilizes a
>  network overlay for packet transport between SFC network elements. The
> reference is just an example of how a network overlay might deal with
> fragmentation and is not a suggestion that NSH adopt that mechanism but
> rather makes the point that it can utilize the existing network overlay
> mechanics.
>
> Jim
>
> From: sfc <[e-mail]> on behalf of "Andrew G. Malis" <
> [e-mail]>
> Date: Thursday, April 28, 2016 at 8:17 AM
> To: Joel Halpern Direct <[e-mail]>
> Cc: "Elzur, Uri" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, Linda
> Dunbar <[e-mail]>
> Subject: Re: [sfc] Suggested wording addtion to the Section 6
> (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt
>
> Joel,
>
> The diagrams in section 6 of RFC 6830 are control plane, not data plane.
> The data plane diagrams are in section 5.
>
> But the overriding question is - without any fields in the NSH header to
> sequence fragments, how can the fragments be correctly reassembled?
>
> Cheers,
> Andy
>
> On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct <
> [e-mail]> wrote:
>
>> The LISP header does not have a fragment flag or fragment offset.  The
>> diagrams in section 6 include the outer encapsulating header (the
>> equivalent of the transport header in SFC.)  Yes, the text is a little hard
>> to follow in this regard.  The LISP working group is going to be rewriting
>> RFC 6830 as part of moving to standards track.
>>
>> So there is no difference in this regard between NSH and LISP.
>>
>> Yours,
>> Joel
>>
>> On 4/27/16 7:02 PM, Andrew G. Malis wrote:
>>
>>> Joel et al,
>>>
>>> All this talk about fragmentation prompted me to re-read section 6 of
>>> the draft, which recommends (as option 3) using the procedures in
>>> section 5.4 of RFC 6830 (presumably with the “NSH header” replacing the
>>> “LISP header” in the description of the procedures in that section).
>>>
>>> So that led me to read that section (and the LISP header definition in
>>> section 5.1), and I see that LISP does fragmentation and reassembly
>>> identically to IPv4, using the Fragment Offset field so that fragments
>>> can be correctly reassembled in the proper order.
>>>
>>> However, the NSH Header doesn’t have a Fragment Offset field or any
>>> other way to order the fragments.
>>>
>>> So how can the procedures in Section 5.4 of 6830 be used?
>>>
>>> Thanks,
>>> Andy
>>>
>>> On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     Both methods are valid, and both depend upon details of the
>>>     underlying packet and the transport.  As such, I don't see why this
>>>     document benefits from describing them, much less why it should mark
>>>     one method as a "should".  Implementation details are likely to be
>>>     more significant than any bit consumption difference between the two
>>>     alternatives.
>>>
>>>     Yours,
>>>     Joel
>>>
>>>
>>>     On 4/27/16 3:40 PM, Linda Dunbar wrote:
>>>
>>>         I suggest adding the following paragraphs after the Bullet 3 of
>>>         the Section 6 Fragmentation Consideration to make the process
>>>         more clear and less controversial:
>>>
>>>
>>>         --------------------------------
>>>
>>>         RFC6830 describes the fragmentation method of breaking the
>>>         original packet into two equal sub-frames and encapsulating
>>>         [LISP Header + Transport header] to each sub-frame.
>>>
>>>         If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC
>>>         Header + Transport Header] will be added to each half frame (or
>>>         the original data frame). As the Transport Header is terminated
>>>         by the next SFF node's tunnel transport layer, the combined two
>>>         sub-frames will have two SFC Headers.
>>>
>>>         Therefore, the fragmentation for NSH encapsulated data frame
>>>         should be done completely by the node tunnel transport layer,
>>>         which should break the [SFC + original packet] into two equal
>>>         sub-frames and each sub-frame being encapsulated with its
>>>         respective tunnel header.  The next SFF node's tunnel transport
>>>         layer should combine the two sub-frames before sending to the
>>>         next node.
>>>
>>>         ------------------------------------------------------
>>>
>>>
>>>         By the way, there are to typo in the Section 6:
>>>         3rd line: "In order the" ==> "In order to"
>>>         Last line of Bullet 2: extra "the" in the "utilized to ensure
>>>         the the required packet".
>>>
>>>
>>>         Hope it helps.
>>>
>>>         Linda
>>>
>>>
>>>
>>>         -----Original Message-----
>>>         From: [e-mail]
>>>         <mailto:[e-mail]>
>>>         [mailto:[e-mail]
>>>         <mailto:[e-mail]>]
>>>         Sent: Wednesday, April 27, 2016 12:40 AM
>>>         To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; [e-mail]
>>>         <mailto:[e-mail]>
>>>         Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>>>
>>>         Hi Joel, all,
>>>
>>>         Please see inline.
>>>
>>>         Cheers,
>>>         Med
>>>
>>>             -----Message d'origine-----
>>>             De : Joel M. Halpern [mailto:[e-mail]
>>>             <mailto:[e-mail]>] Envoyé : mardi 26
>>>             avril 2016 19:18 À : Linda Dunbar; BOUCADAIR Mohamed
>>>             IMT/OLN; Elzur,
>>>             Uri; [e-mail] <mailto:[e-mail]> Objet : Re: [sfc] WG
>>>             last call for
>>>             draft-ietf-sfc-nsh-04.txt
>>>
>>>             With regard to Transport tunnel fragementation, that seems
>>>             an issue
>>>             for the transport protocol.  I don't actually object to a
>>>             sentence,
>>>             but it does not seem that it will accomplish anything.
>>>
>>>
>>>         [Med] I would like to see some text added to the draft.
>>>
>>>
>>>             With regard to packets fragmented by the source, I
>>>             completely disagree
>>>             with your assertion.  If an SFF were to reassemble the
>>>             packets, that
>>>             would be a violation of its job.
>>>
>>>
>>>         [Med] I agree with you.
>>>
>>>           There is no reason for an SFF to
>>>
>>>             reassemble a packet fragmented by the source.  The
>>>             classifier may have
>>>             to do some interesting things in order to properly classify
>>>             succeeding
>>>             fragments, but that is an implementation issue (most commonly
>>>             addressed with virtual reassembly, which doe snot delay the
>>>             fragments.)  We don't specity that.
>>>
>>>
>>>         [Med] Still, the external behavior of the classifier needs to be
>>>         clear in the document. I don't find any text in the draft saying
>>>         for instance that an NSH header must be present in all
>>>         fragments. (There some processing that might be needed at the
>>>         SFF to "do its job" with regards to fragments (receive out of
>>>         order fragments + forwarding policy on the full packet).)
>>>
>>>
>>>             If an SF needs to reassemble fragments to do its job, that
>>>             is up to
>>>             the SF.  Some will need to actually reassemble.  Some will
>>>             need to
>>>             perform virtual reassembly, and some will happily process the
>>>             fragments.  I can not see what the NSH document could
>>>             possibly mandate.
>>>
>>>
>>>         [Med] Fully agree.
>>>
>>>
>>>             Yours,
>>>             Joel
>>>
>>>             On 4/26/16 11:47 AM, Linda Dunbar wrote:
>>>
>>>                 Joel,
>>>
>>>                 I think the document should add the description on the
>>>                 following two
>>>                 fragmentation scenarios:
>>>
>>>                 - Transport tunnel generated fragmentation: When a packet
>>>                 fragmentation is caused by transport tunnel (i.e. various
>>>                 encapsulations), the termination point of the transport
>>>                 tunnel is
>>>                 responsible for re-assembling the fragmented pieces of
>>>                 the packet.
>>>                 Since there won't be any SFF nodes in between the
>>>                 Transport Tunnel,
>>>                 the tunnel generated fragmentation does not require any
>>>                 actions by
>>>                 SFF nodes or SF nodes.
>>>
>>>
>>>                 - Source node generated fragmentation (after adding on
>>>                 the NSH
>>>                 header): When fragmentation has to be performed for a
>>>                 packet being
>>>                 encapsulated with the NSH header, either the
>>>                 intermediate SFF nodes
>>>                 or the SF nodes have to be able to reassemble the
>>>                 fragmented pieces.
>>>
>>>
>>>
>>>
>>>                 Cheers,
>>>
>>>
>>>                 Linda
>>>
>>>                 -----Original Message----- From: Joel M. Halpern
>>>                 [mailto:[e-mail]
>>>                 <mailto:[e-mail]>] Sent: Tuesday, April 26,
>>>                 2016 10:33 AM
>>>                 To: Linda Dunbar; [e-mail]
>>>                 <mailto:[e-mail]>; Elzur, Uri;
>>>                 [e-mail] <mailto:[e-mail]> Subject: Re: [sfc] WG
>>>                 last call for
>>>                 draft-ietf-sfc-nsh-04.txt
>>>
>>>                 Re-reading your note, it is possible that you are
>>>                 referring only to
>>>                 the case of transport generated fragmentation of the
>>>                 outer packet.
>>>                 I had assumed you were not talking about that, since the
>>>                 resulting
>>>                 fragments will not all have NSH headers.  As with any
>>> tunnel
>>>                 technology, if the tunnel chooses to fragment at its
>>>                 layer, then the
>>>                 tunnel is responsible for reassembly.  That would be
>>>                 invisible to
>>>                 the SFF.
>>>
>>>                 Yours, Joel
>>>
>>>                 On 4/26/16 11:10 AM, Linda Dunbar wrote:
>>>
>>>                     Agree with Med.
>>>
>>>                     Even if each fragment piece of a packet with NSH
>>>                     header carries the
>>>                     NSH header, the intermediate SFF nodes still need to
>>>                     put together
>>>                     all the fragments together before passing the whole
>>>                     data frame to
>>>                     the SF.
>>>
>>>                     Linda
>>>
>>>                     -----Original Message----- From: sfc
>>>                     [mailto:[e-mail]
>>>                     <mailto:[e-mail]>]
>>>                     On Behalf Of [e-mail]
>>>                     <mailto:[e-mail]> Sent: Monday,
>>>                     April 25,
>>>                     2016 9:42 AM To: Elzur, Uri; Joel M. Halpern;
>>>                     [e-mail] <mailto:[e-mail]> Subject:
>>>                     Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>>>
>>>                     Re-,
>>>
>>>                     How do you instruct the transport layer to ALWAYS
>>>                     prepend an NSH
>>>                     header even for fragments? Or you don't care about
>>> that?
>>>
>>>                     Thank you.
>>>
>>>                     Cheers, Med
>>>
>>>                         -----Message d'origine----- De : Elzur, Uri
>>>                         [mailto:[e-mail]
>>>                         <mailto:[e-mail]>] Envoyé : lundi 25
>>>                         avril 2016 16:26 À
>>>                         : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;
>>>                         [e-mail] <mailto:[e-mail]> Objet
>>>                         : RE: [sfc] WG last call for
>>>                         draft-ietf-sfc-nsh-04.txt
>>>
>>>                         Hi Med
>>>
>>>                         Not to repeat my position, but I'll do it anyhow
>>>                         :-) As NSH is
>>>                         *NOT* a transport, dealing with fragmentation is
>>>                         left to the
>>>                         Transport used.
>>>
>>>                         The model I use for NSH, is basically similar to
>>>                         VXLAN . It is an
>>>                         overly.
>>>
>>>                         Thx
>>>
>>>                         Uri ("Oo-Ree") C: 949-378-7568 <tel:[phone]
>>> >
>>>
>>>
>>>                         -----Original Message----- From: sfc
>>>                         [mailto:[e-mail]
>>>                         <mailto:[e-mail]>]
>>>                         On Behalf Of [e-mail]
>>>                         <mailto:[e-mail]> Sent:
>>>                         Monday, April 25,
>>>                         2016 7:18 AM To: Joel M. Halpern
>>>                         <[e-mail] <mailto:[e-mail]
>>> >>;
>>>                         [e-mail] <mailto:[e-mail]>
>>>                         Subject: Re: [sfc] WG last call for
>>>                         draft-ietf-sfc-nsh-04.txt
>>>
>>>                         Hi Joel,
>>>
>>>                         Please see inline.
>>>
>>>                         Cheers, Med
>>>
>>>                             -----Message d'origine----- De : Joel M.
>>> Halpern
>>>                             [mailto:[e-mail]
>>>                             <mailto:[e-mail]>] Envoyé : lundi
>>>                             25 avril 2016 15:48 À
>>>                             : BOUCADAIR Mohamed IMT/OLN; [e-mail]
>>>                             <mailto:[e-mail]> Objet : Re: [sfc] WG
>>>                             last call for draft-ietf-sfc-nsh-04.txt
>>>
>>>                             If I am understanding you correctly Med, you
>>>                             are asking that the
>>>                             NSH draft specify how service chaining
>>>                             should cope with packets
>>>                             that have been fragmented?
>>>
>>>
>>>                         [Med] To be accurate, I'm asking to assess
>>>                         whether there are
>>>                         implications. If there are, then the draft
>>>                         should be updated
>>>                         accordingly.
>>>
>>>                             NSH, and the SFF functionality, does not
>>> care.
>>>
>>>
>>>                         [Med] I'm not that sure. Some typical
>>>                         implications are listed
>>>                         below:
>>>
>>>                         * SFF: If the NSH header is present only in the
>>>                         a fragment but SFF
>>>                         didn't maintained a state, subsequent fragments
>>>                         won't be
>>>                         appropriately processed. * SFC-aware function:
>>>                         if prepending a
>>>                         context information depends on the full packet,
>>>                         not only a
>>>                         fragment.
>>>
>>>                         It just does its job.
>>>
>>>                         [Med] which may be disturbed in some situations
>>>                         as listed in the
>>>                         examples above.
>>>
>>>                             Ingress and intermediate classifiers may
>>>                             cope with fragments in
>>>                             any number of ways.
>>>
>>>                         Specifying such is clearly out of scope for this
>>>                         draft.
>>>
>>>                         [Med] The purpose is not to specify the internal
>>>                         implementation
>>>                         details but the external behavior of the
>>>                         classifier function when
>>>                         it comes to handle fragments. That behavior may
>>>                         have an incidence
>>>                         on SFF, in particular. The purpose is not to
>>>                         recommend the maximum
>>>                         resources to be dedicated to out of order
>>>                         fragments nor the
>>>                         timeout to cache those; these considerations are
>>>                         of course out of
>>>                         scope. Nevertheless, an implementation should
>>>                         offer a configurable
>>>                         parameter so that an operator tweak those
>>>                         according to its
>>>                         context.
>>>
>>>                             I suppose one could write an informational
>>>                             draft on possible ways
>>>                             of coping.  The IETF has not usually
>>>                             published such.
>>>                             Service functions have to cope with
>>>                             fragmented packets just as
>>>                             they had to before the advent of NSH, so
>>>                             describing that is
>>>                             clearly not needed here.
>>>
>>>
>>>                         [Med] The advent of NSH has the following
>>>                         implications: * it
>>>                         exacerbates fragmentation. Handing over this
>>>                         issue to the
>>>                         transport layer may lead to interoperability
>>>                         issues. * the
>>>                         chaining may not be efficient if fragments are
>>>                         inappropriately
>>>                         handled.
>>>
>>>                         Introducing NSH should not degrade the overall
>>>                         service compared to
>>>                         legacy service deployment schemes.
>>>
>>>
>>>                             Yours, Joel
>>>
>>>                             On 4/25/16 3:00 AM,
>>>                             [e-mail]
>>>                             <mailto:[e-mail]> wrote:
>>>
>>>                                 Re-,
>>>
>>>                                 I hear you, but my comment is that we
>>>                                 need, as a WG, to decide
>>>                                 what to
>>>
>>>                             put in the draft. FWIW, I'm discussing two
>>>                             fragmentation
>>>                             issues:
>>>
>>>
>>>                                 (1) Fragmentation that is caused by
>>>                                 prepending an SFC header.
>>>                                 (2) Handling fragments at the ingress of
>>>                                 an SFC-enabled domain.
>>>
>>>                                 Increasing the MTU is for sure a
>>>                                 recommendation is to be
>>>                                 explicitly
>>>
>>>                             called out in the text (see my first
>>> message).
>>>
>>>
>>>                                 There are other issues that need to be
>>>                                 discussed, e.g., how to
>>>                                 deal with
>>>
>>>                             fragments in SFFs/Classifiers?
>>>
>>>
>>>                                 It is also "prudent" to check that no
>>>                                 issues will be experienced
>>>                                 in SFF
>>>
>>>                             to handle fragments. If an SFC header is
>>>                             prepended for all
>>>                             fragments, I'm not sure there
>>>
>>>                                 is any particular issue at the SFF
>>>                                 level, except if
>>>                                 stripping/adding
>>>
>>>                             context TLVs depends on the full packet (not
>>>                             just fragment). It
>>>                             is warranted to consider a little bit this
>>>                             point before declaring
>>>                             there is no issue.
>>>
>>>
>>>                                 For point (1), declaring fragmentation
>>>                                 out of scope would be
>>>                                 meant that
>>>
>>>                             an implementation must be prepared to
>>>                             receive fragments with or
>>>                             without NSH header as this is a decision
>>>                             that is left to the
>>>                             transport encapsulation. This is a
>>>                             requirement per se!
>>>
>>>
>>>                                 I won't reiterate all the comments I
>>>                                 have about the current
>>>                                 wording of
>>>
>>>                             this section.
>>>
>>>
>>>                                 Cheers, Med
>>>
>>>                                     -----Message d'origine----- De :
>>>                                     Elzur, Uri
>>>                                     [mailto:[e-mail]
>>>                                     <mailto:[e-mail]>] Envoyé
>>>                                     : lundi 25 avril 2016
>>>                                     08:30 À : BOUCADAIR Mohamed IMT/OLN;
>>>                                     Thomas Narten;
>>>                                     [e-mail] <mailto:[e-mail]>
>>>                                     Objet : RE: [sfc] WG last call for
>>>                                     draft-ietf-sfc-nsh-04.txt
>>>
>>>                                     Hi Med
>>>
>>>                                     My point is that Fragmentation is
>>>                                     yet another transport related
>>>                                     issue
>>>
>>>                             that
>>>
>>>                                     is beyond the scope of NSH and
>>>                                     beyond the charter of the WG, so
>>>                                     it
>>>
>>>                             doesn't
>>>
>>>                                     really belong in the draft. We are
>>>                                     providing an advice as
>>>                                     extending the size of the packet may
>>>                                     lead to fragmentation, but
>>>                                     as you check RFC 7348 VxLAN, which
>>>                                     my create the same issue,
>>>                                     you'll find it doesn't even
>>>
>>>                             relate
>>>
>>>                                     to it.
>>>
>>>                                     Thx
>>>
>>>                                     Uri ("Oo-Ree") C: 949-378-7568
>>>                                     <tel:[phone]>
>>>
>>>
>>>                                     -----Original Message----- From: sfc
>>>                                     [mailto:[e-mail]
>>>                                     <mailto:[e-mail]>] On
>>>                                     Behalf Of
>>>                                     [e-mail]
>>>                                     <mailto:[e-mail]>
>>> Sent:
>>>                                     Sunday, April 24, 2016
>>>                                     10:32 PM To: Elzur, Uri
>>>                                     <[e-mail]
>>>                                     <mailto:[e-mail]>>;
>>>                                     Thomas Narten
>>>
>>>                             <[e-mail] <mailto:[e-mail]
>>> >>;
>>>
>>>                                     [e-mail] <mailto:[e-mail]>
>>>                                     Subject: Re: [sfc] WG last call for
>>>                                     draft-ietf-sfc-nsh-04.txt
>>>
>>>                                     Hi Uri,
>>>
>>>                                     That's another option that needs to
>>>                                     be discussed/investigated.
>>>                                     I'm
>>>
>>>                             afraid
>>>
>>>                                     this is not the rationale adopted in
>>>                                     -04 since it includes some
>>>                                     text
>>>
>>>                             that
>>>
>>>                                     is far to be sufficient to ensure
>>>                                     interoperable
>>>                                     implementations.
>>>
>>>                                     BTW, saying that nsh does not need
>>>                                     to deal with fragmentation
>>>                                     because
>>>
>>>                             it
>>>
>>>                                     is transport-independent is not IMHO
>>>                                     a good strategy to adopt
>>>                                     here
>>>
>>>                             because
>>>
>>>                                     it opens the door for interoperable
>>>                                     issues, it may lead to
>>>                                     sub-optimal implementations if the
>>>                                     sfc information is present
>>>                                     only in one
>>>
>>>                             fragments,
>>>
>>>                                     etc.
>>>
>>>                                     My comments are related to the
>>>                                     current text in the -04.
>>>                                     This text needs
>>>
>>>                             to
>>>
>>>                                     be fixed somehow.
>>>
>>>                                     Cheers, Med
>>>
>>>                                         -----Message d'origine----- De :
>>>                                         Elzur, Uri
>>>                                         [mailto:[e-mail]
>>>                                         <mailto:[e-mail]>]
>>>                                         Envoyé : dimanche 24 avril
>>>                                         2016 17:36 À : BOUCADAIR Mohamed
>>>                                         IMT/OLN; Thomas Narten;
>>>                                         [e-mail]
>>>                                         <mailto:[e-mail]> Objet :
>>>                                         RE: [sfc] WG last call for
>>>                                         draft-ietf-sfc-nsh-04.txt
>>>
>>>                                         Hi Med
>>>
>>>                                         I see no need to specify the
>>>                                         exact behavior as NSH is
>>>                                         transport independent i.e. like
>>>                                         NSH interaction with any other
>>>                                         Transport eh issue of
>>>                                         Fragmentation is to be dealt in
>>>                                         a way
>>>                                         that matches the mechanisms
>>>                                         supported by the Transport used
>>>                                         and do not belong in the NSH
>>> draft
>>>
>>>                                         Thx
>>>
>>>                                         Uri ("Oo-Ree") C: 949-378-7568
>>>                                         <tel:[phone]>
>>>
>>>
>>>                                         -----Original Message----- From:
>>> sfc
>>>                                         [mailto:[e-mail]
>>>                                         <mailto:[e-mail]>]
>>>                                         On Behalf Of
>>>                                         [e-mail]
>>>                                         <mailto:
>>> [e-mail]>
>>>                                         Sent: Thursday, April 14,
>>>                                         2016 12:43 AM To: Thomas Narten
>>>                                         <[e-mail]
>>>                                         <mailto:[e-mail]>>;
>>>                                         [e-mail]
>>>                                         <mailto:[e-mail]> Subject:
>>>                                         Re: [sfc] WG last call for
>>>                                         draft-ietf-sfc-nsh-04.txt
>>>
>>>                                         R-,
>>>
>>>                                         In addition to other pending
>>>                                         issues raised for this draft, I
>>>                                         would like to raise this
>>>                                         additional one about Section 6.
>>>
>>>                                         == 6.  Fragmentation
>>> Considerations
>>>
>>>                                         NSH and the associated transport
>>>                                         header are "added" to the
>>>                                         encapsulated packet/frame.  This
>>>                                         additional information
>>>                                         increases
>>>
>>>                             the
>>>
>>>                                         size of the packet.  In order
>>>                                         the ensure proper forwarding of
>>>                                         NSH data, several options for
>>>                                         handling fragmentation and
>>>                                         re-assembly exist:
>>>
>>>                                         1.  Jumbo Frames, when
>>>                                         supported, enable the transport
>>>                                         of NSH
>>>                                         and associated transport packets
>>>                                         without requiring
>>>                                         fragmentation.
>>>
>>>                                         2.  Path MTU Discovery
>>>                                         [RFC1191]"describes a technique
>>> for
>>>                                         dynamically discovering the
>>>                                         maximum transmission unit (MTU)
>>> of
>>>
>>>                             an
>>>
>>>                                         arbitrary internet path" and can
>>>                                         be utilized to ensure the
>>>
>>>                         the
>>>
>>>                                         required packet size is used.
>>>
>>>                                         3.  [RFC6830] describes two
>>>                                         schemes for fragmentation and
>>>                                         re-
>>>
>>>                             assembly
>>>
>>>                                         in section 5.4. ==
>>>
>>>                                         * The text is weak for a
>>>                                         Standard track document that is
>>>                                         intended to solve the problem in
>>>
>>> https://tools.ietf.org/html/rfc7498#section-
>>>
>>>                         2.12.
>>>
>>>                                         There should be a clear behavior
>>>                                         to be followed by an
>>>
>>>                         implementation.
>>>
>>>                                         Further, I would avoid the use
>>>                                         of words such as "can".
>>>
>>>                                         * The text covers only
>>>                                         fragmentation when it is induced
>>>                                         by SFC
>>>                                         operations, it does not discuss
>>>                                         the treatment of a fragment
>>>                                         when received in an SFC domain.
>>>                                         IMHO, the draft should also
>>>                                         specify the behavior of the
>>>                                         Classifier with regards to
>>>                                         fragments for the sake of proper
>>>                                         SFC operation. Applying
>>>                                         classification policies may
>>>                                         require the
>>>
>>>                                     full packet, not only a fragment.
>>>
>>>                                         In particular, dedicated
>>>                                         resources should dedicated for
>>>                                         handling out of order fragments.
>>>                                         Of course, it is out of scope
>>>                                         of this document to describe how
>>>                                         SFs handle fragments.
>>>
>>>                                         * If an SFC header is prepended
>>>                                         for all fragments, I'm not
>>>                                         sure there is any particular
>>>                                         issue at the SFF level...except
>>>                                         if stripping/adding context TLVs
>>>                                         depends on the full packet
>>>                                         (not just fragment). It is
>>>                                         warranted to consider a little
>>> bit
>>>                                         this point before declaring there
>>>
>>>                             is
>>>
>>>                                     no issue.
>>>
>>>
>>>                                         * The text states "several
>>>                                         options". This may be interpreted
>>>                                         as if implementing one of them
>>>                                         is sufficient...which is not
>>>                                         true. The first two points
>>>                                         contribute to minimize the
>>>                                         fragmentation risk, but
>>>                                         fragmentation may still be
>>>                                         experienced
>>>                                         (e.g., other shims are prepended
>>>                                         by other nodes for some other
>>>                                         purposes, nested nsh, etc.)
>>>
>>>                                         * The first two points have
>>>                                         nothing to do with reassembly.
>>>
>>>                                         * The support of jumbo frames by
>>>                                         a router/device does not mean
>>>                                         that it can make use of it.
>>>                                         Appropriate MTU configuration
>>>                                         should be undertaken in a
>>>                                         consistent manner within an SFC
>>>                                         domain. The text should be
>>>                                         updated to make it is about
>>>                                         (consistent) MTU
>>>
>>>                         configuration.
>>>
>>>
>>>                                         * BTW, shouldn't the text be
>>>                                         reworded to recommended to
>>>                                         increase the MTU of **all
>>>                                         nodes** of an SFC-enabled domain
>>> by
>>>                                         at least the length of SFC
>>>                                         header + transport header?
>>>
>>>                                         * Bullet 2, how PMTU discovery
>>>                                         is actually used in this
>>>                                         context? Do you assume that all
>>>                                         SFC-aware nodes will issue
>>>                                         such messages towards other
>>>                                         SFC-aware node, arbitrary
>>>                                         destination, else?
>>>
>>>                                         * Bullet 2, I would drop
>>>                                         "describes a technique for
>>>                                         dynamically discovering the
>>>                                         maximum transmission unit
>>>                                         (MTU) of an arbitrary internet
>>>                                         path".
>>>
>>>                                         * Bullet 2, s/ the the/the.
>>>
>>>                                         * The reference to the LISP
>>>                                         specification raises two concerns
>>>                                         and one comment:
>>>
>>>                                         (1) I don't think it is a good
>>>                                         approach that fragments induced
>>>                                         by the network are passed to
>>>                                         their ultimate destinations as
>>>                                         such
>>>
>>>                         (stateless).
>>>
>>>                                         IMO, reassembly should be done
>>>                                         within the SFC domain
>>>                                         (responsible for fragmentation)
>>>                                         not passed away. (2) Does the
>>>                                         stateful mode require all SFC
>>>                                         data plane elements maintain a
>>>                                         full list of MTU for the any
>>>                                         SFF/SF instance of the SFC
>>>
>>>                                     domain?
>>>
>>>
>>>                                         The current text suggests that
>>>                                         [RFC6830] should be listed as
>>>                                         normative reference (not an
>>>                                         informative one). I would
>>>                                         personally favor removing the
>>>                                         reference to LISP (as it is an
>>>                                         Experimental RFC).
>>>
>>>                                         * The security section of the
>>>                                         draft may be augmented with
>>>                                         informational
>>>                                         fragmentation-related pointers
>>> to:
>>>                                         e.g., RFC1858 (Security
>>>                                         Considerations for IP Fragment
>>>                                         Filtering), RFC3128 (Protection
>>>                                         Against a Variant of the Tiny
>>>                                         Fragment Attack), and RFC 4963
>>>                                         (IPv4 Reassembly Errors at High
>>>                                         Data Rates).
>>>
>>>                                         Cheers, Med
>>>
>>>                                             -----Message d'origine-----
>>>                                             De : sfc
>>>                                             [mailto:[e-mail]
>>>                                             <mailto:[e-mail]
>>> >]
>>>                                             De la part de
>>>                                             [e-mail]
>>>                                             <mailto:
>>> [e-mail]>
>>>                                             Envoyé : lundi 11 avril
>>>                                             2016 13:14 À : Thomas
>>>                                             Narten; [e-mail]
>>>                                             <mailto:[e-mail]> Objet
>>>                                             : Re:
>>>                                             [sfc] WG last call for
>>>                                             draft-ietf-sfc-nsh-04.txt
>>>
>>>                                             Dear Thomas, all,
>>>
>>>                                             As I mentioned during the
>>>                                             meeting, there are several
>>>                                             issues
>>>                                             that are not covered in the
>>>                                             last version of the draft. I
>>>                                             already provided examples of
>>>                                             the issues offline as
>>> requested
>>>                                             by Martin.
>>>
>>>                                             Cheers, Med
>>>
>>>                                                 -----Message
>>>                                                 d'origine----- De : sfc
>>>                                                 [mailto:
>>> [e-mail]
>>>                                                 <mailto:
>>> [e-mail]>]
>>>                                                 De la part de Thomas
>>> Narten
>>>                                                 Envoyé : jeudi 31 mars
>>>                                                 2016 04:48 À :
>>>                                                 [e-mail]
>>>                                                 <mailto:[e-mail]>
>>>                                                 Objet : [sfc] WG last
>>>                                                 call for
>>>                                                 draft-ietf-sfc-nsh-04.txt
>>>
>>>                                                 Dear WG:
>>>
>>>                                                 This note begins a WG
>>>                                                 last call on
>>>                                                 draft-ietf-sfc-nsh-04.txt
>>>                                                 (
>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/)
>>>
>>>
>>>
>>>             The editors of the NSH document have indicated that they have
>>>
>>>                                                 addressed all known
>>>                                                 comments and that there
>>>                                                 are no open
>>>                                                 issues with the current
>>>                                                 version of the document.
>>>
>>>                                                 Substantive comments to
>>>                                                 the list please,
>>>                                                 editorial comments
>>>                                                 can go directly to the
>>>                                                 document editors.
>>>
>>>                                                 We'll also get a brief
>>>                                                 update from the editors
>>>                                                 at next
>>>                                                 week's meeting. If there
>>>                                                 are any remaining issues
>>>                                                 with the
>>>                                                 document, raising them
>>>                                                 before the meeting would
>>> be
>>>                                                 especially helpful.
>>>
>>>                                                 For the chairs, Thomas
>>>
>>>
>>> _______________________________________________
>>>                                                 sfc mailing
>>>                                                 list [e-mail]
>>>                                                 <mailto:[e-mail]>
>>>
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>>
>>>
>>> _______________________________________________
>>>                                             sfc mailing
>>>                                             list [e-mail]
>>>                                             <mailto:[e-mail]>
>>>
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>>
>>>
>>> _______________________________________________
>>>                                         sfc mailing
>>>                                         list [e-mail]
>>>                                         <mailto:[e-mail]>
>>>
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>>
>>>
>>> _______________________________________________
>>>                                     sfc mailing
>>
>>
>