Hi, Joel,

Many thanks for your review! Please see inline.

> On Jun 30, 2017, at 10:13 AM, Joel Jaeggli <[email protected]> wrote:
> 
> Reviewer: Joel Jaeggli
> Review result: Has Nits
> 
> I have reviewed
> 
> draft-ietf-spring-oam-usecase-06 as par of the OPS directorate review cycle
> forIETF last call.
> 
> In general I think this document is ready to go however I have a couple of
> concerns that should probably at least be discussed prior to IESG review.
> 
>> From my vantage point the document is not so much a description of a use case
> or requirements as it is the architectural wrapper around
> draft-ietf-mpls-spring-lsp-ping. It's most helpful in my opinion to review 
> this
> one as though the other one was the companion document, from this vantage 
> point
> I think the later document is effectively normatively referenced. Similarly 
> the
> readiness of the later document (which is a bit earlier in it's lifecycle)
> raises the question of whether this one is ready to go.
> 

I agree that this is not so much a use-case document — however, I would not 
characterize this document as standing atop draft-ietf-mpls-spring-lsp-ping. In 
fact, the monitoring system described, as the text already shows, can use other 
OAM protocols and formats. That is, if the PMS uses for example BFD, and 
therefore it does not use RFC 8029, then it cannot use 
draft-ietf-mpls-spring-lsp-ping (because those are extensions of MPLS LSP 
Ping). Further, the PMS can perfectly well (as already described) function with 
RFC 8029 and without draft-ietf-mpls-spring-lsp-ping. 
draft-ietf-mpls-spring-lsp-ping provides very useful enhancements that the 
system can leverage, but the system is not wrapped around the specification of 
draft-ietf-mpls-spring-lsp-ping.

We tried to clarify this a bit in the version just submitted.

> in the security considerations section the document notes:
> 
>   As mentioned in the introduction, a PMS monitoring packet should
>   never leave the domain where it originated.  It therefore should
>   never use stale MPLS or IGP routing information.
> 
> I think is is more accurate to say:
> 
> Use of stale MPLS or IGP routing information could cause a PMS monitoring
> packet to leave the domain where it originated. PMS monitoring packets should
> not be sent using stale MPLS or IGP routing information.
> 
> As it is necessary to know that the information is stale is order to follow 
> the
> instruction, as is the case with for example convergence events that may be
> ongoing at the time of diagnostic measurement.
> 


Agreed. We added this text. Note please that additionally, we significantly 
revamped the Security Considerations section.

Thanks!

> 

—
Carlos Pignataro, [email protected]

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to