Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

[Greg Mirsky <[e-mail]>]

Hi Carlos,
you have valid interpretation of the text in its current version. And I
think that if it was in the document as you have presented (or very close
to it), it would address my concern, as you've provided clear and
unambiguous definition of what considered as OAM packet in SFC - packet
that carries OAM information as payload that immediately follows the NSH.

Regards,
Greg

On Mon, Jul 3, 2017 at 5:37 PM, Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Hi Andy,
>
> I believe that s/packet/information/ can actually cause more confusion
> that bring clarity.
>
> O=0 means that the payload is a user packet. O=1 means the payload is an
> OAM packet.
>
> However, this is independent of the Metadata, since some Metadata can be
> OAM-ish (as a timestamp). And this is also independent of a NULL payload as
> in Adrian’s draft.
>
> A user packet with OAM-ish metadata will have O=0.
>
> The text can always be polished more — I am not sure if we might be in
> diminishing return territory.
>
> (I would not oppose a clarification that speaks to the metadata
> independence of O for user packets, although maybe that does belong in
> other documents)
>
> Thanks!
>
> Carlos.
>
> On Jul 1, 2017, at 5:26 PM, Andrew G. Malis <[e-mail]> wrote:
>
> Joel,
>
> I would like to suggest changing:
>
> O bit: Setting this bit indicates an Operations, Administration, and
>    Maintenance (OAM) packet.  The actual packet format and processing of
>    SFC OAM messages is outside the scope of this specification (see
>    [oam-frame]).
>
> to:
>
> O bit: Setting this bit indicates the presence of Operations,
> Administration, and
>    Maintenance (OAM) information.  The actual OAM information format and
> processing
>    is outside the scope of this specification (see  [oam-frame]).
>
>
> The reason for this change is that we don’t yet know if the format of OAM
> information, and whether it will be in metadata, packet contents, or
> both. Thus, we don’t yet even know if there will be “OAM packets” per se,
> as data packets could possibly also carry OAM information in the metadata.
>
> If this change is acceptable, then the following two paragraphs should
> also be amended to:
>
>    SF/SFF/SFC Proxy/Classifer implementations that do not support SFC
>    OAM procedures SHOULD discard packets with O bit set, but MAY support
>    a configurable parameter to enable forwarding received packets with the
> O bit
>    set unmodified to the next element in the chain.  Forwarding
>    packets with the O bit set unmodified by SFC elements that do not
> support SFC OAM
>    procedures may be acceptable for a subset of OAM functions, but can
>    result in unexpected outcomes for others, thus it is recommended to
>    analyze the impact of forwarding a packet with the O bit set for all
> OAM functions
>    prior to enabling this behavior.  The configurable parameter MUST be
>    disabled by default.
>
>    The O bit MUST be set for packets containing OAM information and MUST
> NOT be set for
>    packets without OAM information.  The O bit MUST NOT be modified along
> the SFP.
>
>
> Finally, I’ve seen both “O bit” and O-bit” used in the document. The
> document should choose one.
>
> Thanks,
> Andy
>
>
> On Sat, Jul 1, 2017 at 5:11 PM, Joel M. Halpern <[e-mail]>
> wrote:
>
>> The definition of the O bit in the document is:
>>
>> O bit: Setting this bit indicates an Operations, Administration, and
>>    Maintenance (OAM) packet.  The actual packet format and processing of
>>    SFC OAM messages is outside the scope of this specification (see
>>    [oam-frame]).
>>
>>    SF/SFF/SFC Proxy/Classifer implementations that do not support SFC
>>    OAM procedures SHOULD discard packets with O-bit set, but MAY support
>>    a configurable parameter to enable forwarding received SFC OAM
>>    packets unmodified to the next element in the chain.  Forwarding OAM
>>    packets unmodified by SFC elements that do not support SFC OAM
>>    procedures may be acceptable for a subset of OAM functions, but can
>>    result in unexpected outcomes for others, thus it is recommended to
>>    analyze the impact of forwarding an OAM packet for all OAM functions
>>    prior to enabling this behavior.  The configurable parameter MUST be
>>    disabled by default.
>>
>>    The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM
>>    packets.  The O-bit MUST NOT be modified along the SFP.
>>
>> This seems to me a VERY clear description of when the bit is to be set,
>> and what handling is required when packets with this bit are received at an
>> NSH support entity.
>>
>> If you consider this wording unclear, please propose specific text to
>> improve it.
>>
>> Yours,
>> Joel
>>
>> On 7/1/17 5:02 PM, Greg Mirsky wrote:
>>
>>> Hi Joel,
>>> by all means, I'm not asking to hold NSH document until SFC OAM
>>> solutions progress. But NSH refers to OAM packet and, in my view, it is too
>>> ambiguous term. Please consider, OAM packet may be:
>>>
>>>   * control message of active SFC OAM protocol carried as payload;
>>>   * control message of active SFC OAM protocol carried as metadata;
>>>   * control information and/or measurement results of hybrid SFC OAM
>>>     protocol carried as metadata
>>>
>>> If work on OAM framework is progressing, perhaps all the OAM related
>>> discussion as well as allocation of the O-bit itself can be moved there.
>>>
>>> As co-author of several SFC OAM drafts I'd note that none of them has
>>> dependency on where OAM information must be placed, metadata or payload.
>>> But clear and unambiguous definitionsof OAM packet and interpretation of
>>> O-bit are very much needed and will help to progress SFC OAM solutions.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Sat, Jul 1, 2017 at 1:21 PM, Joel M. Halpern <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     Greg, the editors are working on the revision of the OAM Framework
>>>     document.
>>>
>>>     <chair hat on>
>>>     More importantly, we have been careful that the NSH document does
>>>     not normatively depend upon the OAM specification.  This was
>>>     discussed with the working group several times, and the OAM wording
>>>     in -13 is the result of that discussion.
>>>     </chair hat on>
>>>     <chair hat off>
>>>     Are you really asking that we hold up RFC publication of the NSH
>>>     document until we have agreement on all of the complex OAM issues
>>>     (such as in-situ, etc.)  I observe a steady rate of new OAM
>>>     proposals, with new behaviors.  That seems to indicate that such
>>>     ahold-up would be almost indefinite.
>>>     </chair hat off>
>>>
>>>     Yours,
>>>     Joel M. Halpern
>>>
>>>     On 7/1/17 3:39 PM, Greg Mirsky wrote:
>>>
>>>         Hi Joel, Adrian, et. al,
>>>         you'd expect that I'll look into OAM bit and wording on OAM
>>>         packet first. And so I had. I'm concerned that NSH refers to
>>>         expired and, frankly, stalled document that had not been
>>>         discussed for too long. I believe the NSH document should have
>>>         or refer to clear definition of SFC OAM packet before it defines
>>>         interpretation of O-bit flag. draft-farrel-sfc-convent correctly
>>>         points that in current form O-bit indicates presence of OAM
>>>         information which can be either as metadata or as payload. I
>>>         believe that we must have more clear and deterministic
>>>         definition of OAM packet as current, in my opinion, may cause
>>>         problems for HW-based SFC OAM support.
>>>
>>>         Regards,
>>>         Greg
>>>
>>>         On Thu, Jun 29, 2017 at 4:22 PM, Joel Halpern Direct
>>>         <[e-mail] <mailto:[e-mail]>
>>>         <mailto:[e-mail]
>>>         <mailto:[e-mail]>>> wrote:
>>>
>>>              The -13 will be out in a few days with all the changes.
>>>              That is what we will ask the WG to review.
>>>              If we already had it out, we would have already asked for
>>>         the WG to
>>>              take a last look.
>>>
>>>              Yours,
>>>              Joel
>>>
>>>
>>>              On 6/29/17 7:21 PM, Greg Mirsky wrote:
>>>
>>>                  Hi Joel,
>>>                  is the -12 the latest published version of the NSH
>>>         draft? As I
>>>                  see, it is missing TTL and all related changes:
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         sfc mailing list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/sfc
>>>         <https://www.ietf.org/mailman/listinfo/sfc>
>>>
>>>
>>>
>> _______________________________________________
>> sfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
>
> —
> Carlos Pignataro, [e-mail]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>