Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03

[Kengo NAITO <[e-mail]>]

I have sent comments below to authors.
I would also like to post to the ML.

comments:

1. Why not allow other alternatives?
The document, from the introduction part, says too much that you focus 
on IPFIX.
Using IPFIX application ID format is one most valuable way to describe 
application, however, focusing too much on IPFIX may sometime mislead 
people.
So why not,
  - first write, "This is a draft to discuss using application 
identification as a context"
  - and then write, "There are many alternatives, such as json and other 
formats to describe application identification"
  - finally, "the format of IPFIX application ID is one best practice of 
the metadata format".


2. Concrete use case or "purpose" is needed
This is needed to mention what WG want to solve, or what WG want NSH to do.
I as a carrier engineer have a justification to carry application 
identification.
There are three points:

  -L7 identification is now useful in many ways. Visualization of 
traffic, or co-operation with other functions.

  - The cost of application identification(say, DPI) is quite 
high.(traffic handling, and also the cost of DPI equipments)

  -There are many data centers to place SFs, and chain them. We cannot 
DPI in every data centers for re-classification or SFForwarding.
If we can carry and re-use(or share) app-id information across DCs, it 
would make good cost reduction.

I think that NSH is the best practice to do such things.
(Also, use case of traversing several data centers is written in 
draft-ietf-sfc-dc-use-cases, which is a WG doucment.)


3. Consideration of MD-Type is needed
I think that consideration is needed before you say "we use MD-Type1".
There may be some case that MD-Type1 is helpful to convey application 
identification. Good example is as is written in current draft.
On the other hand, MD-Type2 may be needed, when the identification 
format do not fit to 4byte x4 context headers.
For example, giving application name as a string or long bit json as a 
metadata, in result of DPI or other functions.

Please let me hear your opinion.

Best regards,
Kengo


On 2016/05/04 1:59, Joel M. Halpern wrote:
> I read this document.
> The problem / task is clearly useful, so I support having the WG adopt a
> document to address it.
> The proposed information structure seems a good start, so I support
> adoption of this document.
>
> I think it would be helped by a little bit of text explaining how this
> would appear, with what length, in an MD-2 TLV, and what happens if the
> inner implicit length and the outer explicit length don't match.
>
> What is unclear to me is: what is the purpose of the YANG model?
> I have no problem with having separate documents defining additional
> TLVs.  We are clearly going to need them.
> But defining a YANG model for each TLV seems really strange.
>
> Yours,
> Joel
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc

-- 
------------------------------------------------
Kengo NAITO
Technology Development
NTT Communications Corporation
Tel: [phone]
E-mail: [e-mail]
------------------------------------------------