Re: [sfc] Some questions about NSH

[[e-mail]]

Hi Paul,

Thanks for your reply.

See my comments labelled [AT] below.

Best Regards.
Ting
 




发件人:         "Paul Quinn (paulq)" <[e-mail]>
收件人:         "[e-mail]" <[e-mail]>, 
抄送:   "[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]>
日期:   2017/05/06 01:55
主题:   Re: Some questions about NSH



Hi Ting, 

Thank you for the review and comments!

Please see comments below.

Paul

On Apr 18, 2017, at 10:02 PM, [e-mail] wrote:

Hi authors， 

After I reviewed the NSH draft, I have some questions and comments.   

1.Section 4: In Figure 8, I think Classifier should also have function to 
select SFP, the Classifier need to know how to forward the traffic to the 
first SFF of the SFP. 


In section 2.1, the classifier definition specifies that the classifier 
delivers the NSH packet to the first SFF.  Bear in mind that the 
classifier and the SFF are logical, and may be co-resident.

[AT]As I understand what your depict, Classifier and first SFF must be 
co-resident.The Classifier can't forward the traffic to first SFF, because 
the Classifier has no capability to select SFP. In addition, in section 
2.1, there are two definitions, one is Classifier, another is Service 
Classifier. What's the difference between them? Are they two entity of SFC 
or a same entity?




2.Section 7.1: There is a mapping between next hop and transport in every 
SFF. So the traffic forwarded from one SFF to anther SFF is on a kind of 
transport tunnel. I think there should be an example to illustrated the 
packet format from SFF on a transport. That is how to choose a specific 
tunnel according to the next hop and tranport in Figure 9, so that the 
packet can be forwarded to right next SFF. And in this part, it is assumed 
that the NVE( function for tunnel) and SFF are co-located. What if they 
are split? There is no specification about it. In my opinion, only if SFF 
forwarding is independent with NVE, so we can say that NSH is agonostic 
with transport. 

We originally had example but the AD and WG agreed that the example did 
not belong in the main protocol draft, hence they were removed.  There was 
some interest in companion drafts that depict transport stacks so perhaps 
that's a place to start?

[AT]I agree. We should consider the impact to each other between NSH and 
transport, and get some output. I have a draft:
https://tools.ietf.org/html/draft-ao-sfc-overlay-01, maybe it's a good 
start:) Let's discuss it further.


3.Section 8.2: There are already Metadata Augment and Metadata Update. 
What about the Metadata Delete? For some cases, one metadata once be used 
by a SF, and the metadata will not by used anymore, maybe the SF should 
delete that metadata if it is not useful anymore. 

That's a good point and I think it's come up before on list but I'm not 
certain.  In general, I view delete as a form of update.

[AT]Update may includes delete. But there is no such description in the 
corresponding part of the draft, and two examples are also only related to 
augment and update. So I suggest we add some clarification in the draft. 
At least to make sure that delete metadta also happens.





Best Regards. 
Ting