Brady Johnson Thanks for your kind answer!.
The additional information is placed in NSH type 2 [1]. Firstly, I write a spec based on the previous spec in ODL-SFC. After writing the spec, I want to join ODL-SFC meeting at Nov21 or Dec 5. Anytime I can participant ODL SFC meeting ? or Is there any another process for participating meeting? Regards, Jaewook Lee. [1] https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-00 ᐧ 2018년 11월 8일 (목) 오후 6:13, Brady Johnson <[email protected]>님이 작성: > Jaewook Lee, > > Welcome to SFC!! That sounds like a very interesting feature. > > Im curious, for the feature work you are proposing, would the additional > information be placed in the traditional NSH metadata headers? If so, would > it be type 1 or type 2 NSH metadata? > > As for the ODL SFC contribution process, first you need to write a spec. > You can find previous SFC specs, and a spec template in the ODL SFC source > code directory: sfc/docs/specs and sfc/docs/specs/specs-template.rst. > Once the spec is approved and merged, then you can start on the code. The > patches need to be submit to gerrit, and they will then be reviewed by the > community members. The patches will be merged by an ODL SFC committer once > accepted. > > Additionally, we have weekly SFC meetings that you could join. You can > find the meeting details on the ODL SFC project wiki: > https://wiki.opendaylight.org/view/Service_Function_Chaining:Main > > Regards, > > Brady > > > > On Thu, Nov 8, 2018 at 6:16 AM Jaewook Lee <[email protected]> > wrote: > >> Dear Brady Johnson and all SFC project members >> >> Hello, I am Jaewook Lee and Ph.D.student at Korea Univ. >> >> I am interested in the in-network monitoring feature, especially in iOAM >> [1], and InT [2]. >> >> However, I know that the iOAM PoT option [3] is included in ODL-SFC, but >> iOAM trace option is not included in ODL-SFC yet. So, I wonder there is a >> reason for not adding the trace option? >> >> In the trace option, when the packet passes SFFs (VPPs), the VPP inserts >> metadata (e.g., timestamp, buffer state) into the packet header and the >> last SFF can return all metadata in the packet header to the monitoring >> engine or data analytics engine. The returned metadata represent RSP state >> and the state of VPPs allocated to RSP. >> >> So, I think the trace option is useful to monitor states of the RSP. >> Moreover, this option can help other projects (DACE in ONAP, PAND). So I >> want to hear any opinion to develop this feature. >> >> Based on the opinion, I want to develop this feature and, later I want to >> contribute this feature for the ODL-SFC project if I can. >> >> So, could you tell me the contribution process in ODL SFC project (e.g., >> summits proposal document like OpenStack or after I develop the code, I >> directly upload my code into Gerrit)? >> >> Yours sincerely, >> Jaewook Lee. >> >> [1] >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/?include_text=1 >> [2] https://p4.org/p4/inband-network-telemetry/ >> [3] >> https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-nsh-encapsulation-for-in-situ-oam-data-01 >> ᐧ >> _______________________________________________ >> sfc-dev mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/sfc-dev >> >
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
