Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

From: "jmh.direct" <[email-masked]>
Date: Mon, 18 Apr 2016 14:24:57 -0400

I will have to look more closely at your comments over all.
Regarding reclassification, classifiers can look at any thing they want.  Looking at SID would seem very rare, but not impossible.
Yours,Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Fedyk, Don" <[email-masked]> Date: 4/18/2016  2:04 PM  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]>, [email-masked] Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt 
Hi Joel

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Wednesday, April 13, 2016 6:10 PM
> To: Fedyk, Don <[email-masked]>; [email-masked]
> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
> 
<Snip>  
> So the question I have is what wording in the NSH draft causes you concern.
> Is there wording in the NSH draft that gives the impression that the SPI / SI is
> only an "identifier"?  Is there wording that we could add that would help?
[Don]  - Since you bring it up: Short answer yes when you get to section 7.4 Figure 14. 

The wording around service forwarding is a bit disconnected spread over a few sections as I understand it there are 3 modes of forwarding operations involving SFFs and SFs that I can see. It was initially discussions on the list about identifiers that made me look more deeply at the forwarding.   I'll keep my comments to service forwarding even though these sections also discuss the mapping to transport I'll focus on SPI and SI handling text. 

Also note there are two occurrences of SPI/ID and 4 occurrences of SPI/SI which I assume are both Service Path Identifier and Service Index.  ID is never defined but SI is equated to node ID or location.  I think SPI/ID is a typo.

With respect to SF and SFF service forwarding 
Section 4 and Sections 7.1 - 7.3 
1) SF NSH Aware using SI decrement.   The SFF sends to an SF that does its thing, and has access to any metadata and passes the packet back (to the same SFF) with a decremented SI.   The SFF then looks up the next hop based on the SPI/SI that maps to another SF optionally via a Network transport mapping.  
2) SF NSH Unaware - A proxy does the decrementing of the SI. 

Observation:  The decrementing of SI keeps the forwarding through an SF to a simplistic form. The text describing this mode implies SF tracking using SI and uses a programmed lookup of the next SPI/SI. 

Note: The text about decrementing to zero seems unnecessary given that any SFF that receives an SPI with any SI value that is unexpected is a forwarding mistake.   Zero is just a specific example of the general case of chain programming where SPI/SI must make sense at each hop. SI of zero does not make sense but neither do any other values of SI that are not programmed for that SPI/SI combination.   
We have always assumed that a control plane/management plane are used to setup/verify chains and some form of OAM should be used to verify chains. 

Since the simplistic form does not allow the more complex chains, in Section 7.4 you have the third mode. 
3) SF NSH Aware with reclassification - This mode allows an SF to do anything to SPI/SI - not specified exactly what, just that reclassification is allowed and presumably SPI and or SI can be changed/reset.   One might imply from reading and figure 14 that this is based on "identifier" (SPI ) lookup and context (or Class) in this example.  It seems to follow that SFs are less concerned with SI actual values.  This sections implies SPI can be changed and does not describe what happens to SI. Presumably the SI is set to some "new' value since an initial classifier would not know what SI should be for all combinations of chains so SI is  location only with respect to a specific SPI. 

Is it true that SI is not consulted when reclassification takes place?   

Cheers
Don 

> 
> Thanks,
> Joel
> 
> On 4/13/16 4:39 PM, Fedyk, Don wrote:
> > Joel
> >
> > I think that
> > https://tools.ietf.org/html/draft-kumar-sfc-nsh-forwarding-00
> > clarifies Service Forwarding (along the chain) versus Packet
> > forwarding (elsewhere).    But this draft points out that the NSH
> > draft is "confusing" with respect to some parts of service
> > forwarding.   And when I and others have asked on the list about
> > subtleties of Service forwarding  behaviors and the relationship of
> > chain ID with various packet formats;  the answers were NSH SID and SI
> > were just identifiers.  So while there is not a statement they are
> > non-forwarding identifiers the confusion still exists because the
> > behavior is not clear. I still think NSH SID and SI  behave as an
> > address space - receive a packet; lookup the address; if recognized
> > process; then place the next hop address (includes not modifying the
> > address in some cases) on the packet and forward on.  If the fields
> > don't match expected values;  drop or exception process.
> >
> > Cheers Don
> >
> >
> >> -----Original Message----- From: Joel M. Halpern
> >> [mailto:[email-masked]] Sent: Wednesday, April 13, 2016 4:09 PM
> >> To: Fedyk, Don <[email-masked]>; Thomas Narten
> >> <[email-masked]>; [email-masked] Subject: Re: [sfc] WG last call for
> >> draft-ietf-sfc-nsh-04.txt
> >>
> >> Given that the draft describes how to use the SFP ID and Index for
> >> forwarding, it would seem very strange to argue that it does not
> >> describe a forwarding behavior, or that those fields are not for use
> >> by forwarding.  It is not REQUIRED that they be used for forwarding
> >> at an SFF, but it is certainly permitted.
> >>
> >> Is there wording in the draft that says that these are non-forwarding
> >> identifiers?  If so, we really should fix that.
> >>
> >> Yours, Joel
> >>
> >> On 4/13/16 4:05 PM, Fedyk, Don wrote:
> >>> Hi Joel
> >>>
> >>> The argument has been put forward that NSH is only carrying
> >>> identifiers.  When I look at NSH service forwarding that I know I
> >>> disagree with that statement.  I think that NSH SID + SI is an
> >>> address space and hence is not completely independent of forwarding.
> >>> The only way I can reason it out is to see other examples of
> >>> complete packet headers and operations per hop.
> >>> There has been a lot of hand waving.
> >>>
> >>> Cheers Don
> >>>
> >>>> -----Original Message----- From: Joel M. Halpern
> >>>> [mailto:[email-masked]] Sent: Wednesday, April 13, 2016
> >>>> 3:59 PM To: Fedyk, Don <[email-masked]>; Thomas Narten
> >>>> <[email-masked]>; [email-masked] Subject: Re: [sfc] WG last call
> >>>> for draft-ietf-sfc-nsh-04.txt
> >>>>
> >>>> I am having trouble following your argument about forwarding in
> >>>> this email.
> >>>>
> >>>> Yes, transports can carry forwarding information.  The SFC
> >>>> archtiecture allows it.  that does not make including service paht
> >>>> identification in ht NSH header either redundant or incorrect.
> >>>>
> >>>> I do not know what you mean by needing more examples of the
> >>>> forwarding. The draft itself describes how the NSH header SFP ID
> >>>> and index can be used for the SFF forwarding decision.  That
> >>>> description seems quite clear to me.  If there is ambiguity or
> >>>> unclarity, please let the WG know, so we can improve it.
> >>>>
> >>>> Yours, Joel
> >>>>
> >>>> On 4/13/16 3:05 PM, Fedyk, Don wrote:
> >>>>> Hi Thomas
> >>>>>
> >>>>> At this point I do not support a last call on the NSH header.
> >>>>> There is a lot of
> >>>> comments and I don't think it is at a point where it is last call
> >>>> ready.
> >>>>>
> >>>>> I have be banging my head against the wall on this one because I
> >>>>> would like
> >>>> more concrete around the forwarding aspects.  I do accept that
> >>>> there is a draft (draft-kumar-sfc-nsh-forwarding-00 ) now that
> >>>> addresses some the confusion in NSH on forwarding and it helps.
> >>>> Although it seems odd to let a NSH draft progress as confusing and
> >>>> to clarify it later in another draft.
> >>>>>
> >>>>> My main objection is related to the fact that for a draft that
> >>>>> claims it is
> >>>> independent of forwarding it simply has not been proven.  That does
> >>>> not mean we need to specify forwarding but I'd still like to see
> >>>> the data formats of what are being "prototyped" today so I can
> >>>> compare with the other data formats that I know today.
> >>>> For example the MAC chaining draft we authored would like to use
> >>>> NSH for metadata but the MAC chaining local MACs bear a
> >>>> relationship with the NSH SDI & SI. In fact without these fields as
> >>>> mandatory it would be more independent in my case.
> >>>> I'm sure there are similar aspects with other transports types but
> >>>> until I see them and the operations I can't assess transport
> >>>> independence claims.
> >>>>>
> >>>>> There are other inconsistencies that I could live with in the
> >>>>> draft relating to
> >>>> the logic of the MD types etc. (A length field seems to be the only
> >>>> thing that is really needed and local context will determine the
> >>>> contents).  But we have made these comments more than once and
> I've
> >>>> seen little acknowledgment that if the NSH data is basically
> >>>> context driven fixed fields and TLVs could be mixed.
> >>>>>
> >>>>> So in short I support of the drafts goals as a way to carry
> >>>>> metadata but it is
> >>>> not ready for last call yet in my opinion.
> >>>>>
> >>>>> Thanks Don
> >>>>>
> >>>>>> -----Original Message----- From: sfc
> >>>>>> [mailto:[email-masked]] On Behalf Of Thomas Narten
> >>>>>> Sent: Wednesday, March 30, 2016 10:48 PM To: [email-masked]
> >>>>>> Subject: [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
> >>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
> >>>>>
> >>>>> _______________________________________________ sfc
> mailing
> >> list
> >>>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
> >>>>>
> >

---

From: "jmh.direct" <[email-masked]>
Date: Tue, 26 Apr 2016 16:03:16 -0400

Doing path MTU discovery instead of fragmentation is a very reasonable strategy, particularly in supporting IPv6.
The point is that there are multiple reasonable responses, depending upon the transport and other factors.  It is not for NSH to mandate one.
Yours,Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: Dave Dolson <[email-masked]> Date: 4/26/2016  3:55 PM  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]>, Ron Parker <[email-masked]>, [email-masked], "Elzur, Uri" <[email-masked]>, [email-masked] Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt 
Fragment reassembly is a computationally expensive process
and tunnel fragmentation can substantially inflate the number of 
packets, so I prefer fragmenting the inner packet.
This allows SFFs and SFs to forward NSH packets without first reassembling
them.

If the inner packet is IPv6 or IPv4 with DF=1, Path-MTU discovery
can be facilitated by sending an ICMP "Packet too big" message to 
the sender. (RFC 1191, RFC 1981)

There is an additional benefit that inner fragmentation/PMTU discovery
allow service chaining to work even if the transport layer does not 
facilitate fragmentation (e.g., when NSH is transported directly over 
Ethernet).

The fragmentation and Path MTU discovery are standard mechanisms,
and permitted to be used for any link, so nothing needs to be
said in the NSH draft to permit this. However, I think it would
be useful to recommend these approaches.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, April 26, 2016 3:12 PM
To: Ron Parker; [email-masked]; Elzur, Uri; [email-masked]
Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

In most tunnel anlysis, a tunnel entry point (in this case, the 
transport interface from the SFC component) can either fragment outer 
or, if available fragment inner.  This is defined by the transport 
technology, not the user.

In the case of SFC NSH, I would usually expect outer fragmentation, 
which is a pure transport issue.  If the innermost packet is IP, and the 
tunnel entry wants to be complicated, it is permitted to fragment the 
inner packet and produce the proper NSH headers for the fragments. 
Inherently, an implementation can only choose to do this if it can 
construct the right metdata to put on each fragment.  I don't actually 
know how to reliably do that, so I don't recommend it.

In either case, the NSH document can't tell the implementation what to 
do or how to do it.

Yours,
Joel

On 4/26/16 2:38 PM, Ron Parker wrote:
> Joel,
>
> I can't say that I disagree with your analysis on the scope.   I think the question raised by some on the thread is if an SFC-node (i.e., classifier, SF, SFF) creates fragments, is the NSH header repeated in each fragment ?    I think the answer is "no".   If so, is it worth stating this explicitly in the document, or is it just obvious that properly layered systems would behave that way.
>
>    Ron
>
>
> Sent: Tuesday, April 26, 2016 1:22 PM
> To: Ron Parker <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]; Elzur, Uri <[email-masked]>; [email-masked]
> At least so far, we have treated the communication between classifier and SFF (ingress or intermediate) as outside of the scope of our work.
> For SF <-> SFF communication we have ntoed the need for a proxy to handle the case when the SF can not accept and return the NSH header, since we assume that is preserved.  Other than that preservation, similar to the above, we have treated the details as outside of our scope. That is because they depend so heavily on the implementation technique used.  (Hypervisor ,_> application communication vs communication inside a user space or communication over an actual Ethernet are all very different.)
>
> Trying to extend the NSH document to address these would be a major change, and would step into the issues related to transport selection, which are explicitly out of scope.
>
> Yours,
> Joel
>
> On 4/26/16 11:58 AM, Ron Parker wrote:
>> Linda,
>>
>> I like the first clause (transport tunnel based fragmentation).
>>
>> Regarding the second (source based), I think there are more subcases to consider:
>>
>> 1.  Propagation of NSH encapsulated packet from classifier to SFF 2.
>> Propagation of NSH encapsulated packet from SFF to SF 3.  Propagation
>> of NSH encapsulated packet from SF to SFF (including possibility that
>> NSH size increased at SF) 4.  Propagation of NSH encapsulated packet
>> from SFF to SFF
>>
>> In each of the 4 cases above,  there is the possibility that MTU will be exceeded and therefore there are procedures to be defined in that eventuality.
>>
>> Thanks.
>>
>>     Ron
>>
>>
>> From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
>> Sent: Tuesday, April 26, 2016 11:48 AM
>> To: Joel M. Halpern <[email-masked]>;
>> [email-masked]; Elzur, Uri <[email-masked]>;
>> [email-masked]
>> 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
>>
>> Sent: Tuesday, April 26, 2016 10:33 AM
>> To: Linda Dunbar; [email-masked]; Elzur, Uri;
>> [email-masked]
>> 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
>>>
>>> From: sfc [mailto:[email-masked]] On Behalf Of
>>> [email-masked]
>>> Sent: Monday, April 25, 2016 9:42 AM
>>> To: Elzur, Uri; Joel M. Halpern; [email-masked]
>>> 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:[email-masked]] Envoyé : lundi 25 avril
>>>> 2016 16:26 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;
>>>> [email-masked] Objet : RE: [sfc] WG last call for
>>>> 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
>>>>
>>>>
>>>> From: sfc [mailto:[email-masked]] On Behalf Of
>>>> [email-masked]
>>>> Sent: Monday, April 25, 2016 7:18 AM
>>>> To: Joel M. Halpern <[email-masked]>; [email-masked]
>>>> Hi Joel,
>>>> Please see inline.
>>>> Cheers,
>>>> Med
>>>>> -----Message d'origine-----
>>>>> De : Joel M. Halpern [mailto:[email-masked]] Envoyé : lundi 25
>>>>> avril 2016 15:48 À : BOUCADAIR Mohamed IMT/OLN; [email-masked] 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, [email-masked] 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:[email-masked]] Envoyé : lundi 25
>>>>>>> avril 2016 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;
>>>>>>> [email-masked] Objet : RE: [sfc] WG last call for
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> From: sfc [mailto:[email-masked]] On Behalf Of
>>>>>>> [email-masked]
>>>>>>> Sent: Sunday, April 24, 2016 10:32 PM
>>>>>>> To: Elzur, Uri <[email-masked]>; Thomas Narten
>>>>> <[email-masked]>;
>>>>>>> [email-masked]
>>>>>>> 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:[email-masked]] Envoyé : dimanche
>>>>>>>> 24 avril 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas
>>>>>>>> Narten; [email-masked] Objet : RE: [sfc] WG last call for
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> From: sfc [mailto:[email-masked]] On Behalf Of
>>>>>>>> [email-masked]
>>>>>>>> Sent: Thursday, April 14, 2016 12:43 AM
>>>>>>>> To: Thomas Narten <[email-masked]>; [email-masked]
>>>>>>>> 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:[email-masked]] De la part de
>>>>>>>>> [email-masked] Envoyé : lundi 11 avril 2016 13:14 À :
>>>>>>>>> Thomas Narten; [email-masked] Objet : Re: [sfc] WG last call for
>>>>>>>>> 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:[email-masked]] De la part de Thomas
>>>>>>>>>> Narten Envoyé : jeudi 31 mars 2016 04:48 À : [email-masked]
>>>>>>>>>> Objet
>>>>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>>>>>>>>>>
>>>>>>>>>> Dear WG:
>>>>>>>>>>
>>>>>>>>>> Substantive comments to the list please, editorial comments
>>>>>>>>>> can go directly to the document editors.
>>>>>>>>>>
>>>>>>>>>> For the chairs,
>>>>>>>>>> Thomas
>>>>>>>>>> _______________________________________________
>>>>>>>>>> sfc mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> sfc mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sfc mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sfc mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>
>>>>>> _______________________________________________
>>>>>> sfc mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
>>

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc