Hi Joel,
I think the following editorial change clarifies your point. Please let me know.
Thanks,
Pablo.
Diff:
====
-> Section 4.16.1 PSP
....
The PSP operation is deterministically controlled by the SR Source
Node. A PSP-flavored SID is used by the Source SR Node when it needs
to instruct the penultimate SR Segment Endpoint Node listed in the
SRH to remove the SRH from the IPv6 header.
PSP allows, for example, for an egress PE to receive a packet with a
segment in the DA of the outer header without any need to process the
SRH.
<NEW>This is useful for example when the SRH contains too many SIDs compared to
the egress PE dataplane capability as advertised in the IGP [§8.1]. In such
case calculating an SRv6 policy to these nodes needs to account for the
availability of the PSP capability upstream to these nodes.</NEW>
SR Segment Endpoint Nodes receive the IPv6 packet with the
Destination Address field of the IPv6 Header equal to its SID
address. A penultimate SR Segment Endpoint Node is one that, as part
of the SID processing, copies the last SID from the SRH into the IPv6
Destination Address and decrements Segments Left value from one to
zero.
....
-> Section 8.1 IGP
The End, End.T and End.X SIDs express topological behaviors and hence
are expected to be signaled in the IGP together with the flavors PSP,
USP and USD.
<OLD>The IGP also advertises the support for SRv6 capabilities of the
node.</OLD>
<NEW>The IGP should also advertise the maximum SRv6 SID depth (MSD) capability
of the node for each type of SRv6 operation. In particular, the SR source
(e.g., H.Encaps), intermediate endpoint (e.g., End, End.X) and final endpoint
(e.g., End.DX4, End.DT6) behaviors. These capabilities are factored in by an SR
Source Node (or a controller) during the SR Policy computation.</NEW>
...
-----Original Message-----
From: Joel Halpern Direct <jmh.dir...@joelhalpern.com>
Sent: martes, 17 de marzo de 2020 18:51
To: Pablo Camarillo (pcamaril) <pcama...@cisco.com>
Cc: spring@ietf.org
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12
Given that the requirement to be able to ignore the routing header predates any
of the SRv6 work, a natural reading would be that ignoring the header is
something the device can already do. In normal situations, the savings for not
doing a check that simple is very small.
Having been told the cost was high, with no further explanation, I am forced to
assume the historical (unfortunate) behavior that made the cost high. If that
explanation is correct, then it has other implications. If that is NOT the
reason that the cost is high, please state what the reason is for it having a
high cost. We are asking devices to support a special feature (PSP) to achieve
the savings. We owe it to folks to explain why we are asking for such a thing.
(And no, the fact that PSP is optional does not change things. If PSP
matters, then it matters. If it doesn't matter, then lets drop it.)
Yours,
Joel
On 3/17/2020 1:43 PM, Pablo Camarillo (pcamaril) wrote:
> Inline
>
> -----Original Message-----
> From: "Joel M. Halpern" <j...@joelhalpern.com>
> Date: Monday, 16 March 2020 at 20:23
> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
> Cc: "spring@ietf.org" <spring@ietf.org>
> Subject: Re: [spring] Question on
> draft-ietf-spring-srv6-network-programming-12
>
> The changes in section 4.16.1 do improve the clarity.
>
> Having said that, the text about motivating PSP reads:
> PSP allows, for example, for an egress PE to receive a packet
> with a segment in the DA of the outer header without any need to
> process the SRH.
> is a very weak and confusing explanation. Given that 8200 requires
> nodes to be able to ignore any routing header with SL=0, the text as
> written seems to be without benefit.
>
> Joel, how do you know whether you can ignore a routing header?
> I believe that the only option is for the router to process the routing
> header to check whether the Segments Left value is equal to zero.
> PSP avoids any routing header processing at the egress PE, as the quoted text
> above states. Hence the benefit.
>
> Thanks,
> Pablo.
>
> Yes, I have seen descriptions of
> the benefits from others on the list. But this text is not it.
>
> If indeed the benefit is a node where any extension header presence
> causes much slower processing (as was alluded to by other posters on the
> list) then it seems that should be acknowledged in the description.
> Doing something slowly is indeed still compliant to 8200.
> I have asked that we go a step further, and acknowledge that such nodes
> have other limitations and that if we are going to make allowance for
> them, we should call out those other issues as well.
>
> Yours,
> Joel
>
> On 3/16/2020 2:55 PM, Pablo Camarillo (pcamaril) wrote:
> > Hi Joel,
> >
> > Please check revision 13 of this document that clarifies the PSP
> section.
> >
> > About your last point:
> > For both SR-MPLS and SRv6, there are restrictions on the path to be
> used, in particular:
> > - the SR policy may only use SIDs instantiated on SR Endpoints.
> > - When computing the SR policy, there are additional restrictions to
> consider, such as the Maximum SID Depth (MSD) capability of nodes in the
> topology. (for SRv6, see section 4 of draft-ietf-lsr-isis-srv6-extensions).
> >
> > Regards,
> > Pablo.
> >
> > -----Original Message-----
> > From: "Joel M. Halpern" <j...@joelhalpern.com>
> > Date: Tuesday, 10 March 2020 at 19:26
> > To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
> > Cc: "spring@ietf.org" <spring@ietf.org>
> > Subject: Re: [spring] Question on
> draft-ietf-spring-srv6-network-programming-12
> >
> > 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
