Daniel,
In you message, do you really mean PPSIs? Or when you say PPSI, are you really
referring to topological instructions?
Ron
Juniper Business Use Only
-Original
Daniel,
I’m not sure that I agree. The PSSI doesn’t represent per-path information. It
represents an instruction to be executed at a segment endpoint.
Ron
Juniper Business Use Only
From: Bernier, Daniel
Sent: Wednesday, September 25,
Ah but Joel,
As was debated over the mailing list, if I have multiple paths (i.e.
unidirectional PPSIs) that go across different PSSIs on intermediate nodes each
of these intermediate nodes needs to figure out which PSSI to apply before
sending to the node next in the forwarding path.
And
SR is Stateless in the sense of not having per-path state. It is not
stateless in a general sense, since otherwise MPLS-SR would not be SR
(it needs label state). So I think we are reading 8402 differently.
We can let the marketing folks fight it out in the marketplace.
Yours,
Joel
On
Hi Ron,
Similarly I would refrain from using the SR acronym since a key characteristic
of the SR architecture as per RFC8402 is statelessness.
As per current SRv6+ documents, state is required for an intermediate node to
add the relevant next PSSIs in DOH. This is whether they are domain-wide
Agree with Stuart.
SRinUDP is a well defined solution, let’s not mix things.
Cheers,
Jeff
On Sep 25, 2019, 2:39 PM +0200, Stewart Bryant ,
wrote:
> I agree.
>
> Inclusion of the term MPLS would cause confusion with
> draft-ietf-mpls-sr-over-ip, which is entitled SR-MPLS over IP. The design
>
I agree.
Inclusion of the term MPLS would cause confusion with
draft-ietf-mpls-sr-over-ip, which is entitled SR-MPLS over IP. The
design decribed in draft-ietf-mpls-sr-over-ip works over both IPv4 and
IPv6. Also course, as Ron states, such a name is not a true refelction
of the design.
-
