Re: [Detnet] Comments on I-D Action: draft-ietf-detnet-oam-framework-01.txt

[Fabrice Theoleyre <[e-mail]>]

Dear Balazs, 

After the call of Yesterday, please find inline the comments of our last modifications.

> TEXT
>   6.   DetNet OAM MUST support bi-directional OAM methods.  Such OAM
>        methods MAY combine in-band monitoring or measurement in the
>        forward direction and out-of-bound notification in the reverse
>        direction, i.e., from egress to ingress end point of the OAM
>        test session.
>> Comment28> " egress to ingress end point" Are these the MEPs?

FT>> we have yesterday a quite long discussion on this problem (are MEP only the ingress/egress nodes?). In particular, PREOF may require to have nodes in charge of elimination / replication. Thus, We changed the assertion 1:
TEXT: "It MUST be possible to initiate DetNet OAM session from any  DetNet node towards another DetNet node(s) within given domain."

FT>> Balazs argued yesterday that the source and destination may be DetNet nodes. So, we insert a novel requirement
TEXT "It MAY be possible to initiate a direct DetNet OAM session from a  DetNet source towards a DetNet destination within given domain."

FT>> We also discussed the problem of bidirectional DetNet flows. 
FT>> We separated now the requirement for bidirectional vs. unidirectional flows. For unidirectional DetNet flows, the forward direction may be in-band, the inverse direction may be out-of-band.
TEXT: « OAM methods MAY combine in-band monitoring or measurement in the forward direction and out-of-bound notification in the reverse direction, i.e., from egress to ingress end point of the OAM test session.»

FT>> For bidirectional DetNet flows, we MUST support two OAM unidirectional sessions 
TEXT: "DetNet OAM MUST support bidirectional DetNet flows, with a pair of OAM sessions, each of them in charge of one of the two directions. »

@all: Please tell us if it is compliant with what you have possibly in mind for uni/bidirectional DetNet flows.


> TEXT
>   13.  DetNet OAM MUST support unidirectional performance measurement
>        methods.  Calculated performance metrics MUST include but are
>        not limited to throughput, packet loss, delay and delay
>        variation metrics.  [RFC6374] provides detailed information on
>        performance measurement and performance metrics.
>> Comment30> How is this point related to requirement 6.5 (also mentioning PM)?
>> Comment31> To be discussed whether adding "out-of-order" characteristics as well here.

FT>> good suggestion, inserted in the list.

> TEXT
>   15.  DetNet OAM MUST support methods to enable survivability of the
>        DetNet domain.  These recovery methods MAY use protection
>        switching and restoration.
>> Comment32> " survivability" term not used in DetNet so far. How it is related to DetNet sub-layers? Is it a forwarding sub-layer functionality?

FT>> We replaced it by availability to be compliant with RAW.

> TEXT
>   16.  DetNet OAM MUST support the discovery of Packet Replication,
>        Elimination, and Order preservation sub-functions locations in
>        the domain.
>   17.  DetNet OAM MUST support testing of Packet Replication,
>        Elimination, and Order preservation sub-functions in the domain.
>> Comment33> "Order" --> "Ordering"
>> Comment34>  "sub-functions" --> "functions". These are functions not sub-functions.

FT>> Greg seems have already change it.

FT>> We will upload the novel version.

Thank you very much for your constructive feedback. 

Cheers,
Fabrice