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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 15 Aug 2016 19:25:08 +0000

Naito san,

Many thanks for your useful and insightful comments!

I believe we incorporated most/all comments and suggestions into a new
revision, at:
URL:            
https://www.ietf.org/internet-drafts/draft-penno-sfc-appid-05.txt
Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-appid/
Htmlized:       https://tools.ietf.org/html/draft-penno-sfc-appid-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-penno-sfc-appid-05

Thanks again!

‹ Carlos.

-----Original Message-----
From: Kengo Naito <[email-masked]>
Date: Tuesday, July 12, 2016 at 12:10 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Jim
Guichard <[email-masked]>
Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Benoit Claise <[email-masked]>,
<[email-masked]>, Carlos Pignataro <[email-masked]>
Resent-Date: Tuesday, July 12, 2016 at 12:10 AM

>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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
>
>-- 
>------------------------------------------------
>Kengo NAITO
>Technology Development
>NTT Communications Corporation
>Tel: +81-50-3813-6053
>E-mail: [email-masked]
>------------------------------------------------