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.  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" <jmh@joelhalpern.com>
> Date: Tuesday, 10 March 2020 at 19:26
> To: "Pablo Camarillo (pcamaril)" <pcamaril@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-bounces@ietf.org> on behalf of Christian Hopps <chopps@chopps.org>
>      > Date: Saturday, 7 March 2020 at 12:50
>      > To: "spring@ietf.org" <spring@ietf.org>
>      > Cc: Christian Hopps <chopps@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
>      >
>      
> 
> 