Hi,
I'm catching up on some of the SPRING drafts, and thought I would have a
look at this one to see how it has progressed since I last reviewed it.
It is so refreshing to see a draft that is not too long - thanks!
I found a whole pile of minor issues and nits, but nothing very big. And
everything should be easy to fix. Once that is done, I would consider
the draft ready to progress.
Thanks for the work.
Adrian
= Puzzling Question =
In section 5 you have
When a PSID is allocated on the egress, it MUST be distributed to the
ingress node of the path that identified by the PSID.
I can accept that the means of doing this could be out of scope for this
document, but I think there is something curious. I can see how the PSID
identifies which path is which at a node that knows the mapping, but I
don't know how that gets conveyed to other nodes. The path is otherwise
indicated by the full SID list, so is the assumption that egress will
communicate with other nodes sending the whole SID list along with the
PSID? Otherwise, I don't see how the distributed PSID is of any use.
= Minor =
Section 3
You have...
[RFC8754] states that
the SR segment endpoint node creates Forwarding Information Base
(FIB) entries for its local SIDs (without constraining the details of
implementation). In order to provide a new independent 128-bit ID
space for PSID, the PSID is required to be stored separating from the
other SIDs (for example in a different table from the FIB).
I am not sure why you find it necessary to constrain the implementation
about how it stores PSIDs, immediately after you note that 8754 does not
constrain the implementation.
Further, is a PSID a local SID or not?
If it is not, why is the first sentence in any way relevant?
If it is, then your second sentence means you are making an Update to
RFC 8754.
It is clear that PSIDs MUST NOT be used for routing (it is less
clear why not!), and I think you have said this well. So why is the
storage mechanism any of your business? Indeed, a FIB lookup of a PSID
could return a "do not forward" indication, or a special null interface,
or "not found".
I would suggest deleting these two sentences.
However, there may be something hiding here which you have not made
clear: Is it required that a PSID value must also not be the same as
any other SID value. I think this is the case (but if it is not the
case then you have work to do!).
Now, this issue resurfaces at the top of 3.1 where you have:
As mentioned above, an SRv6 PSID is stored independent from the FIB,
so that the total 128-bit can be programmed in use.
I think this could be deleted as well.
---
3.1
To avoid the
value conflict, the value of a PSID MUST be global unique within the
SRv6 domain.
This is important!
But there are some things missing:
- What does "global" mean? (SR domain? AS? The world?)
- How is this achieved? (If you use the encoding in 3.1.1 this is easy)
- What happens if there is a clash?
---
3.1
A use case can define its specific structure of the PSID.
Presumably all nodes participating in that use case must agree on the
structure of the PSID. But what happens if a PSID from one use case is
seen by a router that also participates in another use case - how can it
tell the structures apart?
---
4.
You have...
The SRv6 PSID MUST appear only once in the segment list.
Do you mean...
The SRv6 PSID MUST NOT appear more than once in the segment list.
And, per RFC 8754 as updated by draft-ietf-6man-sidlist-clarification,
the Segment List contains entries that are mapped to SIDs, but are not
necessarily SIDs. So, in the case of Segment List compression,
presumably the PSID does not appear explicitly in the SID list.
BTW, the whole issue of segment list compression seems to be forgotten
throughout the document apart from one short mention buried in the
middle of 4.1. It's mainly a problem of use of language.
---
4.1
I like the description of the G Flag as indicating that the final entry
in the Segment List contains (i.e., is mapped to) a 128 bit meta data
value. However, this opens up uses beyond PSID and that leaves the
question of how one would distinguish between different metadata cases:
when does the G Flag indicate the presence of a PSID and when does it
indicate some other metadata?
Although later you have...
When the SRH.G-flag is set, it indicates that a PSID is encoded in
...which suggests that, perhaps, the generality of the G Flag is not
intended.
Then I see:
* Set (1): Indicates that Segment List[n] (the last entry) contains
a Generic Metadata object. The content of this 128-bit field is
not treated as a standard IPv6 destination address for routing
lookup but as an opaque identifier or data payload defined by the
specific application (e.g., a Path Segment Identifier).
* Unset (0): Indicates that Segment List[n] is not valid.
Surely 0 indicates the Segment List[n] is (mapped to) a normal
(routable) SID? Otherwise you've broken backward compatibility etc.
---
6.
What happens if the G Flag is clear, but a PSID is at the bottom of the
SID list. I think that the PSID is easily identified by the egress node,
but is it allowed to process the PSID?
---
6.
What happens if the end of a segment advances to the next SID and that
SID is a PSID, but not a locally assigned PSID? Yes, this is not
supposed to happen, but there is no protection.
If the G Flag is set, the node will know that:
- it is at the bottom of the SID list
- the final SID is a PSID
- the PSID was not locally allocated
...so it will not forward the packet
If the G flag is not set, the node will not know that this is not a
routable SID. So won't it try to forward the packet which is routable
based on the Loc part of the PSID?
= Nits =
Abstract
OLD
The SR architecture can be implemented over an MPLS data plane as
well as an IPv6 data plane.
NEW
The SR architecture can be implemented over an MPLS data plane
(SR-MPLS) as well as an IPv6 data plane (SRv6).
END
---
Abstract
OLD
Currently, Path Segment Identifier (PSID) has been defined to
identify an SR path in SR-MPLS networks, and is used for various use-
NEW
The Path Segment Identifier (PSID) was defined to
identify an SR path in SR-MPLS networks, and is used for various use-
END
---
1.
OLD
To identify an SR-MPLS path, a Path Segment Identifier
is defined in [RFC9545].
NEW
To identify an SR-MPLS path, a Path Segment Identifier (PSID)
is defined in [RFC9545].
END
---
1.
s/384-bits value and a 1280-bits/384-bit value and a 1280-bit/
---
1.
s/are merged/is merged/
---
1.
OLD
distinguish the path in different SR policy
NEW
distinguish the paths in different SR policies
END
---
1.
OLD
However, an SRv6 policy may need to measure a
segment list in its own candidate path, where the packets statistics
associated with this segment list is independent with other segment
lists in other SRv6 policies even if the same segment list is used.
NEW
However, an SRv6 policy may require that the
traffic is measured for a specific segment list in its own candidate
path, where the packet statistics associated with this segment list
are independent from the traffic for segment lists in other SRv6
policies even if the same segment list is used.
END
---
1.
OLD
Without a Path ID to specify the path will cause the statistic of the
traffic from multiple paths using the same segment list under
different SRv6 policies merge into an aggregated result on the egress
endpoint node.
NEW
Without a Path ID to specify the path, the traffic statistic from
multiple paths using the same segment list under different SRv6
policies will be merged into an aggregated result on the egress
endpoint node.
END
---
1.
s/a new SRv6 segment/a new SRv6 segment identifier/
s/which in total is an 128-bits value,/which i a 128-bit value,/
s/has the better processing/has better processing/
s/Using an SRv6 PSID is used in reduced/Using an SRv6 PSID in reduced/
---
1.
OLD
can solve the problem of cannot identifying a
segment list by the reduced segment list,
NEW
can solve the problem of not being able to identify a
segment list from the reduced segment list,
END
---
1.2
If you are going to include "SR-MPLS" and "SRv6 path", I think you also
need to include "SRv6".
---
Outside the term "SRv6 Path Identifier" you use "SRv6 Path" and "SRv6
path". Pick one and make sure section 1.2 is consistent.
---
2.
OLD
packets counts/timestamps
NEW
packet counts/timestamps
END
---
3.
s/A PSID is used for identify/A PSID is used to identify/
---
3.
OLD
In normal cases, each segment list will have
a its own PSID with different value. However, depending on the use
case, different segment list might use the same value PSID, causing
the statistics of these SRv6 path are merged on the egress node. For
example, a use case may use the same PSID for some or all the segment
list under a Candidate path, or even some or all Candidate Path
within an SRv6 policy.
NEW
In normal cases, each segment list will have
its own PSID with a different value. However, depending on the use
case, different segment lists might use the same PSID, causing the
statistics of these SRv6 paths to be merged on the egress node. For
example, a use case may use the same PSID for some or all the segment
lists under a Candidate path, or even all Candidate paths within an
SRv6 policy.
END
---
Within the document you have:
Candidate Path
Candidate path
candidate path
Pick one.
---
3.
OLD
For example, the same segment list in different Candidate
Path or SR policy may use different PSIDs for identifying its path to
distinguish the statistics data of other SRv6 path in other SRv6
policies using the same segment list.
NEW
For example, the same segment list in different Candidate
Paths or SR policies may use different PSIDs to identify its path to
distinguish the statistics data of other SRv6 paths in other SRv6
policies using the same segment list.
END
---
3.1
Does Figure 1 add anything to the document? I see you don't reference it
and it doesn't seem to make anything clearer.
---
3.1
s/A future document MAY/A future document may/
s/further new formats/further formats/
---
3.1.1
s/suggested to follows/suggested to follow/
---
3.1.1
Does Figure 2 add anything to the document? You have already referenced
RFC 8986, and there is no actual change from what that RFC defines.
---
4. and Figure 3
I think you should...
OLD
As depicted
in figure.3, PSID MUST be placed at SegmentList[n] in the SRH, where
n equals SRH.LastEntry.
NEW
The PSID, if present, MUST be placed to be mapped from the final
entry in the Segment List in the SRH.
END
And that would mean that Figure 3 contains no new information and can
safely be deleted.
---
4.1
The pseudocode has ref1 and ref2
The text has Ref1 and Ref2
---
You have
performance measurement
Performance measurement
Performance Measurement
Make a choice.
---
6. (similar to 4)
Probably replace...
* The SRv6 PSID MUST appear only once in a segment list
...with...
* The SRv6 PSID MUST NOT appear more than once in a segment list
---
6.
Expand SL on first use.
---
7.
This document also requests IANA to allocate bit position TBA1 within
the "Segment Routing Header Flags" registry defined in [RFC8402].
I think that should be RFC 8754
---
8.
A bit odd that the first paragraph says "no additional security
considerations" and then you have quite a lot of text describing
security considerations.
---
It's not a requirement, but it might be really nice to include an
Operational Considerations section per draft-ietf-opsawg-rfc5706bis.
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
