Dear All,
I concur with all what has been said in support of the adoption of this
draft by SPRING WG. The document is well-written, addresses the real
problem in SR-MPLS, and the proposed solution is technically viable.
My comments and questions are entirely for further discussion:
- would the
I am not quite sure what it means to do a two way path measurement in
MPLS SR since MPLS SR defines a per packet unidirectional path. However,
assuming that this makes sense, I don't see how the return path
information is carried in the RFC6374 message. The draft does not ask
IANA for any ne
+1.
I have been following this draft from its -00 revision. The current revision
has resolved most of the issues I (and others) have been raised (e.g.,
elimination of excessive options).
>From my POV, in its current state the draft meets two basic requirements for
>the WG adoption:
1.
Dear Spring,
We have submitted a new revision of
draft-filsfils-spring-srv6-network-programming. There are several minor updates
to the document, mainly addressing ICMP and having better alignment with SRH
draft. Also, based on WG feedback, we have split the document moving the
illustrations i
