Hi,
This document has been significantly improved since I reviewed version -08
I do have a few comments on this version that I think could be usefully
considered before publication.
Best regards
Stewart
----------
3.1. Path Segment for Performance Measurement
As defined in [RFC7799], performance measurement can be classified
into Passive, Active, and Hybrid measurement. Since Path Segment is
encoded in the SR-MPLS Label Stack as shown in Figure 1, existing
implementation on the egress node can be leveraged for measuring
packet counts using the incoming SID (the PSID).
For Passive performance measurement, path identification at the
measuring points is the pre-requisite. Path Segment can be used by
the measuring points (e.g., the ingress and egress nodes of the SR
path or a centralized controller) to correlate the packet counts and
timestamps from the ingress and egress nodes for a specific SR path,
then packet loss and delay can be calculated for the end-to-end path,
respectively.
Path Segment can also be used for Active performance measurement for
an SR path in SR-MPLS networks for collecting packet counters and
timestamps from the egress node using probe messages.
Path Segment can also be used for In-situ OAM for SR-MPLS to identify
the SR Path associated with the in-situ data fields in the data
packets on the egress node.
Path Segment can also be used for In-band PM for SR-MPLS to identify
the SR Path associated with the collected performance metrics.
SB> Is it assumed that the PSID will always be present in the packet, and if
not that an ELI/EL will always be present? If so this should be stated. If the
PSID is inserted just for a measurement and there is no consistent EL, the path
will change and invalidate the measurement. This issue really needs to be
clarified in the text.
==========
3.2. Path Segment for Bidirectional SR Path
In the current SR architecture, an SR path is a unidirectional path
[RFC8402]. In order to support bidirectional SR paths, a
straightforward way is to bind two unidirectional SR paths to a
single bidirectional SR path. Path Segments can then be used to
identify and correlate the traffic for the two unidirectional SR
paths at both ends of the bidirectional path.
SB> I bought this issue up before and see that it has not been addressed.
The text needs to be much specific as to how the unidirectional paths are
created to achieve this property. You cannot construct a bidirectional path
from two arbitrary unidirectional paths in a hop-by hop network even less so
one that includes ECMP. The path will be loosely bidirectional through
constrained endpoints, but not strictly bidirectional. This is because each
node makes it own independent choice of next hop and thus the link from it to A
may not be the link on which it receives packets from A.
You can achieve bidirectionally with end to end adjacency SIDs imposed by an
SDN controller but then you do not need to use the method proposed above.
This needs a more detailed description on the degree of directionality and how
the paths are instantiated.
==========
3.4. Nesting of Path Segments
/--------\ /--------\ /--------\
/ \ / \ / \
A{ Access }B{ Aggregation }C{ Core }D
\ / \ / \ /
\--------/ \--------/ \--------/
Sub-path(A->B) Sub-path(B->C) Sub-path(C->D)
|<--------------->|<-------------->|<-------------->|
E2E Path(A->D)
|<------------------------------------------------->|
+------------+
~A->B SubPath~
+------------+ +------------+
|s-PSID(A->B)| ~B->C SubPath~
+------------+ +------------+
| BSID(B->C) | |s-PSID(B->C)|
+------------+ +------------+ +------------+
| BSID(C->D) | | BSID(C->D) | ~C->D SubPath~
+------------+ +------------+ +------------+ +------------+
|e-PSID(A->D)| |e-PSID(A->D)| |e-PSID(A->D)| |e-PSID(A->D)|
+------------+ +------------+ +------------+ +------------+
Figure 2: Nesting of Path Segments
SB> In this approach I am surprised that the the stack exiting node C does not
include s-PSID(C->D). D can infer this I suppose as a fragment of e-PSID(A->D)
but it depends who is allowed to know what in the management of the network.
Also you might need to instrument
C->D which is different from instrumenting A-D. That would suggest that
s-PSID(C->D) was needed.
---------
4. Security Considerations
A Path Segment is used within an SR-MPLS domain [RFC8402] and should
not leak outside the domain, therefore no new security threats are
introduced comparing to current SR-MPLS.
SB> That is not strictly correct. In the example in Fig 2 you expose
e-PSID(A->D) in multiple domains.
The security consideration
of SR-MPLS, such as boundary filtering described in Section 8.1 of
[RFC8402] applies to this document.
SB> That seems to be inconsistent with Fig 2.
============_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
