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

[Joel Halpern Direct <[e-mail]>]

Thanks Andy.  That wording would indeed work for me.
Yours,
Joel

On 4/28/16 11:02 AM, Andrew G. Malis wrote:
> Jim,
>
> The way option 3 is currently worded, there’s no indication that this is
> just an example, and not a direction to use RFC 6830, section 5.4. I
> just had an offline discussion with Joel, and he and I agree that a
> better wording for option 3 would be "Use the fragmentation provided by
> the network overlay mechanics. One example can be found in RFC 6830,
> section 5.4.”
>
> Thanks,
> Andy
>
> On Thu, Apr 28, 2016 at 9:22 AM, Jim Guichard (jguichar)
> <[e-mail] <mailto:[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] <mailto:[e-mail]>> on
>     behalf of "Andrew G. Malis" <[e-mail]
>     <mailto:[e-mail]>>
>     Date: Thursday, April 28, 2016 at 8:17 AM
>     To: Joel Halpern Direct <[e-mail]
>     <mailto:[e-mail]>>
>     Cc: "Elzur, Uri" <[e-mail] <mailto:[e-mail]>>,
>     "[e-mail] <mailto:[e-mail]>"
>     <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Linda
>     Dunbar <[e-mail] <mailto:[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] <mailto:[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]>
>             <mailto:[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]>>
>                     [mailto:[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]>
>                     <mailto:[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]>
>                         <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]>
>             <mailto:[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]>
>                             <mailto:[e-mail]
>             <mailto:[e-mail]>>] Sent: Tuesday, April 26,
>                             2016 10:33 AM
>                             To: Linda Dunbar;
>             [e-mail]
>             <mailto:[e-mail]>
>                             <mailto:[e-mail]
>             <mailto:[e-mail]>>; Elzur, Uri;
>                             [e-mail] <mailto:[e-mail]>
>             <mailto:[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]>
>                                 <mailto:[e-mail]
>             <mailto:[e-mail]>>]
>                                 On Behalf Of
>             [e-mail]
>             <mailto:[e-mail]>
>                                 <mailto:[e-mail]
>             <mailto:[e-mail]>> Sent: Monday,
>                                 April 25,
>                                 2016 9:42 AM To: Elzur, Uri; Joel M.
>             Halpern;
>                                 [e-mail] <mailto:[e-mail]>
>             <mailto:[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]>
>                                     <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]>
>             <mailto:[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]> <tel:[phone] <tel:[phone]>>
>
>
>                                     -----Original Message----- From: sfc
>                                     [mailto:[e-mail]
>             <mailto:[e-mail]>
>                                     <mailto:[e-mail]
>             <mailto:[e-mail]>>]
>                                     On Behalf Of
>             [e-mail]
>             <mailto:[e-mail]>
>                                     <mailto:[e-mail]
>             <mailto:[e-mail]>> Sent:
>                                     Monday, April 25,
>                                     2016 7:18 AM To: Joel M. Halpern
>                                     <[e-mail]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>>;
>                                     [e-mail] <mailto:[e-mail]>
>             <mailto:[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]>
>                                         <mailto:[e-mail]
>             <mailto:[e-mail]>>] Envoyé : lundi
>                                         25 avril 2016 15:48 À
>                                         : BOUCADAIR Mohamed IMT/OLN;
>             [e-mail] <mailto:[e-mail]>
>                                         <mailto:[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]>
>
>             <mailto:[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]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>]
>             Envoyé
>                                                 : lundi 25 avril 2016
>                                                 08:30 À : BOUCADAIR
>             Mohamed IMT/OLN;
>                                                 Thomas Narten;
>                                                 [e-mail]
>             <mailto:[e-mail]> <mailto:[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]>
>                                                 <tel:[phone]
>             <tel:[phone]>>
>
>
>                                                 -----Original
>             Message----- From: sfc
>
>             [mailto:[e-mail] <mailto:[e-mail]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>] On
>                                                 Behalf Of
>
>             [e-mail]
>             <mailto:[e-mail]>
>
>             <mailto:[e-mail]
>             <mailto:[e-mail]>> Sent:
>                                                 Sunday, April 24, 2016
>                                                 10:32 PM To: Elzur, Uri
>                                                 <[e-mail]
>             <mailto:[e-mail]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>>;
>                                                 Thomas Narten
>
>                                         <[e-mail]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>>;
>
>                                                 [e-mail]
>             <mailto:[e-mail]> <mailto:[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]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>]
>                                                     Envoyé : dimanche 24
>             avril
>                                                     2016 17:36 À :
>             BOUCADAIR Mohamed
>                                                     IMT/OLN; Thomas Narten;
>                                                     [e-mail]
>             <mailto:[e-mail]>
>                                                     <mailto:[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]>
>                                                     <tel:[phone]
>             <tel:[phone]>>
>
>
>                                                     -----Original
>             Message----- From: sfc
>
>             [mailto:[e-mail] <mailto:[e-mail]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>]
>                                                     On Behalf Of
>
>             [e-mail]
>             <mailto:[e-mail]>
>
>             <mailto:[e-mail]
>             <mailto:[e-mail]>>
>                                                     Sent: Thursday,
>             April 14,
>                                                     2016 12:43 AM To:
>             Thomas Narten
>                                                     <[e-mail]
>             <mailto:[e-mail]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>>;
>                                                     [e-mail]
>             <mailto:[e-mail]>
>                                                     <mailto:[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]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>]
>                                                         De la part de
>
>             [e-mail]
>             <mailto:[e-mail]>
>
>             <mailto:[e-mail]
>             <mailto:[e-mail]>>
>                                                         Envoyé : lundi
>             11 avril
>                                                         2016 13:14 À :
>             Thomas
>                                                         Narten;
>             [e-mail] <mailto:[e-mail]>
>
>             <mailto:[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]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>]
>                                                             De la part
>             de Thomas Narten
>                                                             Envoyé :
>             jeudi 31 mars
>                                                             2016 04:48 À :
>                                                             [e-mail]
>             <mailto:[e-mail]>
>
>             <mailto:[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]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>
>             https://www.ietf.org/mailman/listinfo/sfc
>
>
>
>             _______________________________________________
>                                                         sfc mailing
>                                                         list
>             [e-mail] <mailto:[e-mail]>
>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>
>             https://www.ietf.org/mailman/listinfo/sfc
>
>
>
>             _______________________________________________
>                                                     sfc mailing
>                                                     list [e-mail]
>             <mailto:[e-mail]>
>                                                     <mailto:[e-mail]
>             <mailto:[e-mail]>>
>
>             https://www.ietf.org/mailman/listinfo/sfc
>
>
>
>             _______________________________________________
>                                                 sfc mailing
>
>
>