Pablo, in your reply below you say that the text in 8200 is "crystal
clear". It requires an interesting lens to find something "crystal
clear" about which so many people have expressed so much disagreement.
While a lawyer may claim to a judge that text in a contract is crystal
clear, it is almost always hyperbole. That may be useful in other
contexts. It is not useful here.
As far as I can tell, the text allows the interpretation that the PSP
protagonists have reached. It also allows other interpretations. In
the absence of clarity, I can not claim that PSP biolates 8200. But it
sure as heck is not "crystal clear".
I also find the articulated use cases for PSP muddy. And as far as I
can tell, if the use cases are accurate, then there is a need for
greater clarity in the underlying drafts (NP because I do not want to
try call back the base SRH document) about the restrictions on paths
that can be used.
Yours,
Joel
On 3/10/2020 2:13 PM, Pablo Camarillo (pcamaril) wrote:
Hi Chris,
Thanks for going through the document.
The behaviors 4.13 (End.B6.Encaps), 4.14 (End.B6.Encaps.Red) and 4.15 (End.BM)
correspond to Binding SIDs [1].
As a result of 4.13 for example, the packet is encapsulated with a new IPv6
header and an SRH that contains the SR policy associated to the BSID.
Once the new IPv6 header is pushed into the packet, the NET-PGM pseudocode
passes this packet to the IPv6 module of the router for transmission.
Normally the Upper-Layer Header should not be processed on a packet with a
BSID, since you have just pushed an SR policy into the packet.
That said, when the ultimate destination is BSID, then the Upper Layer Header
processing is the same to End (4.1).
Hope it clarifies.
Thanks,
Pablo.
[1]. https://tools.ietf.org/html/rfc8402#section-5
-----Original Message-----
From: spring <spring-boun...@ietf.org> on behalf of Christian Hopps
<cho...@chopps.org>
Date: Saturday, 7 March 2020 at 12:50
To: "spring@ietf.org" <spring@ietf.org>
Cc: Christian Hopps <cho...@chopps.org>
Subject: [spring] Question on draft-ietf-spring-srv6-network-programming-12
In sections 4.13, (implicitly in 4.14) and 4.15 a set of steps is
indicated. As far as I can tell the processing of the IPv6 header chain in all
cases is terminated. e.g.,
"
When N receives a packet whose IPv6 DA is S and S is a local End.BM
SID, does:
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
....
Interrupt packet processing and discard the packet.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
....
Interrupt packet processing and discard the packet.
S07. }
S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
....
Interrupt packet processing and discard the packet.
S11. }
....
S15. Submit the packet to the MPLS engine for transmission to the
topmost label.
S16. }
"
The text then says:
When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an SRv6 End.BM SID, process the packet
as per Section 4.1.1.
Why would I ever be processing the upper-layer header at this point?
Thanks,
Chris.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
