Subject: [spring] Question on draft-ietf-spring-srv6-network-programming-12

From: Christian Hopps <[email-masked]>
Date: Sat, 7 Mar 2020 06:48:15 -0500

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.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 10 Mar 2020 18:13:30 +0000

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 <[email-masked]> on behalf of Christian Hopps <[email-masked]>
Date: Saturday, 7 March 2020 at 12:50
To: "[email-masked]" <[email-masked]>
Cc: Christian Hopps <[email-masked]>
Subject: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    "
    
    ....
    ....
    ....
    ....
    
    The text then says:

    
    Thanks,
    Chris.
    _______________________________________________
    spring mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/spring

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Mar 2020 14:25:40 -0400

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

---

From: Christian Hopps <[email-masked]>
Date: Tue, 10 Mar 2020 17:01:38 -0400

> On Mar 10, 2020, at 2:13 PM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]> wrote:
> 
> Hi Chris,
> 

I'm still not clear on things I guess, but your answer leads me to a more basic question:

Section 4.1 described the basic "FIB entry" "End" which says:

  "When N receives a packet whose IPv6 DA is S and S is a local End SID, N does..."

So it's talking about a FIB entry for a "local End SID".

Section 4.1.1 says:

  "When processing the Upper-layer Header of a packet matching a FIB
   entry locally instantiated as an SRv6 End SID"

It's talking about a "FIB entry locally instantiated as an SRv6 END SID"

I'm not understanding how these 2 things are different. 4.1s calling a FIB Entry a "local End SID" 4.1.1 is calling something (different?) a "FIB Entry locally instantiated as an SRv6 END SID".

The terms seem too similar for me to make a distinction, where I feel the document expects me to make one.

Thanks,
Chris.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Mar 2020 09:59:11 +0000

Hi Chris,

They are the same thing. 

Section 3:
   ...
   Its processing is defined in [I-D.ietf-6man-segment-routing-header]
   section 4.3 and reproduced here as a reminder.

      Without constraining the details of an implementation, the SR
      segment endpoint node creates Forwarding Information Base (FIB)
      entries for its local SIDs.

      When an SRv6-capable node receives an IPv6 packet, it performs a
      longest-prefix-match lookup on the packets destination address.
      This lookup can return any of the following:

      - A FIB entry that represents a locally instantiated SRv6 SID

      - A FIB entry that represents a local interface, not locally
        instantiated as an SRv6 SID

      - A FIB entry that represents a non-local route

      - No Match

Section 4:
>   Each FIB entry indicates the behavior associated with a SID instance
>   and its parameters.

Thank you,
Pablo. 

-----Original Message-----
From: Christian Hopps <[email-masked]>
Date: Tuesday, 10 March 2020 at 22:01
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    

    
    
    Section 4.1.1 says:

    

    Thanks,
    Chris.

---

From: Christian Hopps <[email-masked]>
Date: Wed, 11 Mar 2020 07:06:29 -0400

> On Mar 11, 2020, at 5:59 AM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]> wrote:
> 
> Hi Chris,
> 
> They are the same thing. 

Ok, so how do I get on 2 different processing paths for the same thing entry as Section 4.1 cannot lead to processing of an upper-layer header as far as I can tell, yet section 4.1.1 is talking about processing the upper layer header for the same FIB entry.

1) Packet arrives, FIB lookup on packet destination address returns local End SID entry.

2) Start processing the extension headers and arrive at the SRH (which comes prior to the upper-layer header.

   From RFC8200 the extension header order:
      IPv6 header
      Hop-by-Hop Options header
      Destination Options header (note 1)
      Routing header <------------------------------------ SRH
      Fragment header
      Authentication header (note 2)
      Encapsulating Security Payload header (note 2)
      Destination Options header (note 3)
      Upper-Layer header <-------------------------------- Upper Layer Header

3) Process the SRH according to 4.1 for which there is no exit that leads to processing any more headers.

Oh wait...

Is 4.1.1 covering (and only covering) the case where my FIB lookup yields a local End SID, but the packet has no SRH in it? If this is the case then it would make things *way* more clear for the document to state this outright. "When a packet's DA returns a FIB entry for a local END SID, but the packet does not contain an SRH ..." or something like that.

Thanks,
Chris.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Mar 2020 12:16:39 +0000

Hi Chris,

The processing defined in draft-ietf-spring-srv6-network-programming is aligned with the SRH. 
Particularly see https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.3

> Is 4.1.1 covering (and only covering) the case where my FIB lookup yields a local End SID, but the packet has no SRH in it?

It is not *only* covering that case (although that is one of the cases, there are others). You process the extension header chain as defined in RFC8200.
When processing the SRH you follow the processing of 4.1; If you get to the Upper Layer Header, you process it as per 4.1.1

Thank you,
Pablo. 

-----Original Message-----
From: Christian Hopps <[email-masked]>
Date: Wednesday, 11 March 2020 at 12:06
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    

    

    Oh wait...

    Thanks,
    Chris.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Mar 2020 13:34:42 +0000

Pablo, Christian and all,

I respectfully disagree with the statement " The processing defined in draft-ietf-spring-srv6-network-programming is aligned with the SRH".

Specifically, from my POV the SRH draft<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26> does not define anything that looks to me as PSP or USP. And this is strictly orthogonal to whether these operations are or are not allowed by RFC 8200.

I have already pointed to this fact in my message to the SPRING and 6MAN WGs<https://mailarchive.ietf.org/arch/msg/spring/jGV6jAFHYlX9jst6e3v-pHQy4VQ/> from 27.02.20, but I have not seen any response to that so far.

What, if anything, do I miss?

And, if I am right, how can the SRH draft (already in AUTH48 in the RFC Editor queue) be updated to accommodate this functionality?

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Wednesday, March 11, 2020 2:17 PM
To: Christian Hopps <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Chris,

Particularly see https://clicktime.symantec.com/3Fk6N1MiGv1a24wAEJBm4Aq6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6man-segment-routing-header-26%23section-4.3

Thank you,

Pablo.

-----Original Message-----

From: Christian Hopps <[email-masked]<mailto:[email-masked]>>

To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>

Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

    > On Mar 11, 2020, at 5:59 AM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:pcamaril=[email-masked]>> wrote:

          IPv6 header

          Fragment header

    Oh wait...

    Thanks,

    Chris.

    > From: Christian Hopps <[email-masked]<mailto:[email-masked]>>

    > To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>

    > Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

    >> On Mar 10, 2020, at 2:13 PM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:pcamaril=[email-masked]>> wrote:

    >> [1]. https://clicktime.symantec.com/3JQLFT39w4G21fVcTdFS4s46H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402%23section-5

    >> From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Christian Hopps <[email-masked]<mailto:[email-masked]>>

    >> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

    >> Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>

    >>   [email-masked]<mailto:[email-masked]>

    >>   https://clicktime.symantec.com/35TnxQkKM3FCs6rMYT62Jgt6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

    >> [email-masked]<mailto:[email-masked]>

    >> https://clicktime.symantec.com/35TnxQkKM3FCs6rMYT62Jgt6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

    > [email-masked]<mailto:[email-masked]>

    > https://clicktime.symantec.com/35TnxQkKM3FCs6rMYT62Jgt6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

spring mailing list

[email-masked]<mailto:[email-masked]>

https://clicktime.symantec.com/35TnxQkKM3FCs6rMYT62Jgt6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Christian Hopps <[email-masked]>
Date: Wed, 11 Mar 2020 12:07:41 -0400

> On Mar 11, 2020, at 8:16 AM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]> wrote:
> 
> Hi Chris,
> 

Right I had quoted the 8200 processing order so I'm using that as a guide.

> When processing the SRH you follow the processing of 4.1; If you get to the Upper Layer Header, you process it as per 4.1.1

This is what I'm getting at though, if there is an SRH you will enter section 4.1 prior to 4.1.1, and if you are in 4.1 there is no processing path that leads to the upper-layer header. So AFAICT the only way to get to section 4.1.1 is if the FIB entry is a local END SID and there is no SRH.

Thanks,
Chris.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Mar 2020 18:44:26 +0000

Hi Chris,

Indeed, an IPv6 packet with no SRH (and FIB entry is local End SID) is one way to get to the Upper Layer Header processing defined in 4.1.1.
Another way is to have a FIB entry bound to an End.DT* or End.DX* behavior. In these cases the ULH processing occurs if the SRH has SL=0 or there's no SRH.

Many thanks,
Pablo.

-----Original Message-----
From: Christian Hopps <[email-masked]>
Date: Wednesday, 11 March 2020 at 17:08
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    

    
    Thanks,
    Chris.

---

From: Christian Hopps <[email-masked]>
Date: Wed, 11 Mar 2020 15:20:53 -0400

> On Mar 11, 2020, at 2:44 PM, Pablo Camarillo (pcamaril) <[email-masked]> wrote:
> 
> Hi Chris,
> 

Ah right, sorry that's right there in the document, it's easy too lose track of all this when multitasking on other things. :)

So if you don't mind, going back to my original question of how this works with Binding SID cases... You replied:

   "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)."

Can you expand on "when the ultimate destination is BSID"? Do you mean when the ultimate destination of the packet is the same node N that is currently processing the BSID FIB entry? If so then that will have to be handled in whatever way it should be after it is resubmitted to either IPv6 or MPLS engines and forwarded and then decapsulated. There won't be anymore header processing to follow from 4.{13,14,15} though. Given something has been added (an IPv6 header or an MPLS label stack) that still needs to get processed and removed before any upper-layer header of the now encapsulated packet gets looked at.

I also find another bit of text confusing in these sections:

  "An End.BM SID is never the last SID, and any SID instantiation is
   associated with an SR-MPLS Policy B."

Is that text is saying that if one lands on a BSID one can always expect more SIDs to be used in moving the packet (b/c of pushing an new IPv6 encap or MPLS label stack)? It's confusing b/c it certainly can read that a BSID can't be the "Last Segment" in an SRH, but that doesn't seem like a reasonable restriction.

Thanks,
Chris.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 12 Mar 2020 10:06:14 +0000

Hi Chris, 

The Binding SIDs have a restriction not to be the last SID in a SID list. This applies to all three Binding SID behaviors defined in draft-ietf-spring-network-programming (End.B6.Encaps, End.B6.Encaps.Red and End.BM) and is indicated by the statements such as "An End.B6.Encaps SID is never the last segment in a SID list." in section 4.13.

More precisely, when a node processes the SRH of a packet whose IPv6 Destination Address matches a locally instantiated SRv6 Binding-SID behavior (any of the three) and it is not the last segment in the SID list, it steers the packet into the associated SR Policy (either by performing an IPv6 encapsulation or by pushing an MPLS label stack on top of the existing packet).

However, if the binding SID is the last SID in a SID list or the IPv6 DA in a packet with no SRH, then the router will generate an ICMP Parameter Problem message with code 4. In either of those two cases, the packet is not steered in the SR Policy and the source is notified of the issue.

This restriction exists for two reasons:
First, the primary use-case for the Binding-SID concept is to apply an intermediate SR Policy that steers the packet along a particular path in an intermediate sub-domain, but the original SID-list is expected to steer the traffic up to the egress node of the SR domain. This means that the final segment in the original SID-list is usually an End.D* (VPN) segment at the egress node.

Second, the processing a Binding-SID at a last position in a SID list requires a different processing. First you would need to decapsulate the packet (since it has reached it final destination) and then re-encapsulate it (or push a label stack on top of the inner packet).

Many thanks,
Pablo.

-----Original Message-----
From: Christian Hopps <[email-masked]>
Date: Wednesday, 11 March 2020 at 20:21
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    

    

    
    
    Thanks,
    Chris.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Mar 2020 10:33:05 +0000

Pablo, Chris and all,

I have not found the restriction for Binding SID not being the last SID in the SID list in RFC 8402 or RFC 8666.

And I think that no such limitation exists in SR-MPLS, where a binding SID can be easily be the last SID in the LIST of SIDs in the SR policy that is used to deliver L3VPN traffic in an SR-based deployment of inter-AS Option C BGP/MPLS IP VPNs:

-          The ASBR of the AS hat contains the specific egress PR implements an intra-AS SR policy that goes to this PE, and allocates a Binding SID to steer packets into it

-          The ASBR of the AS  that contains the specific ingress PE allocates an EPE SID to steer packets it receives from the PEs in  this AS to the ASBR of the domain that contains the specific egress PE

-          The ingress PE implements an intra-AS SR policy going to the ASBR of this AS, augments it with the EPE SID to reach the ASNR of the AS that contains the specific egress PE and with the Binding SID allocated by this ASBR to reach the specific egress PE to obtain the inter-AS SR policy

-          VPN-IP routes are advertised by the egress PE to the ingress PE with the egress PE as their BGP NH, and the ingress PE resolved these routes using an inter-AS SR policy that, from its POV, has the Binding SID as the last entry in the SID list

-          VPN application labels carried in the VPN-IP routes do not represent any SIDs at all.

Did I miss something substantial?

Is the restriction you define here specific to just SRv6?

Regards, and lots of thanks in advance,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, March 12, 2020 12:06 PM
To: Christian Hopps <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Chris,

Many thanks,

Pablo.

-----Original Message-----

    > On Mar 11, 2020, at 2:44 PM, Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks,

    Chris.

    >> On Mar 11, 2020, at 8:16 AM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:pcamaril=[email-masked]>> wrote:

    >> Particularly see https://clicktime.symantec.com/a/1/OOssComq7nKv3aheXcw3XaZubndcUPTiP4r7XKVYET0=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6man-segment-routing-header-26%23section-4.3

    >>>> [1]. https://clicktime.symantec.com/a/1/ilkEJxP-mj7tnQF8crEOD_-axeoYHnBkoeJojGc0dEc=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402%23section-5

    >>>> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

    >>>> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

    >>> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

    >> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

spring mailing list

https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Mar 2020 11:06:36 +0000

Hi Sasha,

In SR-MPLS, we have the inner VPN label and then we can have the BSID label. Similarly for SRv6, we have the VPN SID (e.g. End.DT4) and the BSID (i.e. End.B6.Encaps).

I hope that clarifies.

Thanks,
Ketan

From: spring <[email-masked]> On Behalf Of Alexander Vainshtein
Sent: 12 March 2020 16:03
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; Christian Hopps <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Pablo, Chris and all,

  *   The ASBR of the AS hat contains the specific egress PR implements an intra-AS SR policy that goes to this PE, and allocates a Binding SID to steer packets into it
  *   The ASBR of the AS  that contains the specific ingress PE allocates an EPE SID to steer packets it receives from the PEs in  this AS to the ASBR of the domain that contains the specific egress PE
  *   The ingress PE implements an intra-AS SR policy going to the ASBR of this AS, augments it with the EPE SID to reach the ASNR of the AS that contains the specific egress PE and with the Binding SID allocated by this ASBR to reach the specific egress PE to obtain the inter-AS SR policy
  *   VPN-IP routes are advertised by the egress PE to the ingress PE with the egress PE as their BGP NH, and the ingress PE resolved these routes using an inter-AS SR policy that, from its POV, has the Binding SID as the last entry in the SID list
  *   VPN application labels carried in the VPN-IP routes do not represent any SIDs at all.

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, March 12, 2020 12:06 PM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Chris,

Many thanks,

Pablo.

-----Original Message-----

    Thanks,

    Chris.

spring mailing list

---

From: Christian Hopps <[email-masked]>
Date: Thu, 12 Mar 2020 08:08:30 -0400

> On Mar 12, 2020, at 6:06 AM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]> wrote:
> 
> Hi Chris, 
> 
> However, if the binding SID is the last SID in a SID list

This is the Segments Left == 0 case?

> or the IPv6 DA in a packet with no SRH, then the router will generate an ICMP Parameter Problem message with code 4. In either of those two cases, the packet is not steered in the SR Policy and the source is notified of the issue.

So looping back to my earlier comments on 4.1.1, but in this context. The only way to arrive at this text in 4.{13,14,15}:

   "When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.B6.Encaps SID, process the
   packet as per Section 4.1.1."

is for there to be no SRH in the packet?

Thanks,
Chris.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 12 Mar 2020 12:57:23 +0000

Inline. This one is short.

Many thanks,
Pablo.

-----Original Message-----
From: Christian Hopps <[email-masked]>
Date: Thursday, 12 March 2020 at 13:08
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    

Yes.

    

Yes, but to be precise: IPv6 packet with any kind extension header(s) but no SRH.
    
    Thanks,
    Chris.

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Thu, 12 Mar 2020 13:21:02 +0000

Hi Pablo and Chris:

In my understanding, and avoiding the ambiguous reading as Chris from section 4.13 (14, 15) in SRv6 NPG as below; the text as below (the same as S01-s04 in section4.13) May be replaced by s01-s04 in section 4.3.1.1 in SRH draft, which can bring the processing to lead to section 4.1.1 in SRv6 NPG when BSID is last segment in SRH (i.e. SL==0);
Section 4.1 in SRv6 NPG:
Endpoint:
S01. When an SRH is processed {
  S02.   If (Segments Left == 0) {
  S03.      Send an ICMP Parameter Problem message to the Source Address
               Code 4 (SR Upper-layer Header Error),
               Pointer set to the offset of the upper-layer header.
               Interrupt packet processing and discard the packet.
  S04.   }

Section 4.3.1.1 in SRH draft;
4.3.1.1.  SRH Processing

   S01. When an SRH is processed {
   S02.   If Segments Left is equal to zero {
   S03.     Proceed to process the next header in the packet,
            whose type is identified by the Next Header field in
            the Routing header.
   S04.   }

Cheers!

Wang Weibin

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, March 12, 2020 8:57 PM
To: Christian Hopps <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Many thanks,
Pablo.

-----Original Message-----
From: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 12 March 2020 at 13:08
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    > On Mar 12, 2020, at 6:06 AM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:pcamaril=[email-masked]>> wrote:
    >
    > Hi Chris,
    >

Yes.

    Thanks,
    Chris.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 12 Mar 2020 16:10:02 +0000

Hi Wang Weibin,

What is the benefit to ignore and keep processing to get to the same end result?
Maybe you could gain some pps by stopping the processing as soon as you know that the BSID will not be executed and you need to send ICMP.

Many thanks,
Pablo.

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Thursday, 12 March 2020 at 14:21
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, Christian Hopps <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Pablo and Chris:

Cheers!

Wang Weibin

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, March 12, 2020 8:57 PM
To: Christian Hopps <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Many thanks,
Pablo.

-----Original Message-----
From: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 12 March 2020 at 13:08
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Yes.

    Thanks,
    Chris.

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Fri, 13 Mar 2020 06:41:18 +0000

Hi Pablo:

I agree with what you said and your intention behind the entire section 4.1 within SRv6 NPG draft, including subsection 4.1.1;

But from the entire text of section 4.1 in SRv6 NPG, literally, the processing on packet with active SID being last SID in SRH(with SL==0) will be terminated at s02-s04 in 4.1, therefore, it has not chance for the same packet processing to arrive at subsection 4.1.1;

Is there any logical relation between section 4.1 and subsection 4.1.1 for the same packet processing? in my understanding, it is independent for the meaning of content between 4.1 and subsection 4.1.1.

Cheers!

Wang Weibin

From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Friday, March 13, 2020 12:10 AM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>; Christian Hopps <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Wang Weibin,

Many thanks,
Pablo.

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 12 March 2020 at 14:21
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Pablo and Chris:

Cheers!

Wang Weibin

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, March 12, 2020 8:57 PM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Many thanks,
Pablo.

-----Original Message-----
From: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 12 March 2020 at 13:08
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Yes.

    Thanks,
    Chris.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 13 Mar 2020 13:47:38 +0000

Hi Wang Weibin,

Thank you for your comment. Inline.

Cheers,
Pablo.

Date: Friday, 13 March 2020 at 07:43

Hi Pablo:

Correct.

Both are presenting the processing for a packet matching a FIB entry instantiated as an End segment.
4.1 describes the SRH processing. 4.1.1 describes the Upper Layer Header processing.

Cheers!

Wang Weibin

Hi Wang Weibin,

Many thanks,
Pablo.

Hi Pablo and Chris:

Cheers!

Wang Weibin

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, March 12, 2020 8:57 PM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Many thanks,
Pablo.

-----Original Message-----
From: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 12 March 2020 at 13:08
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Yes.

    Thanks,
    Chris.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 16 Mar 2020 18:55:36 +0000

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" <[email-masked]>
Date: Tuesday, 10 March 2020 at 19:26
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    
    
    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Mar 2020 15:23:17 -0400

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

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 17 Mar 2020 17:43:59 +0000

Inline

-----Original Message-----
From: "Joel M. Halpern" <[email-masked]>
Date: Monday, 16 March 2020 at 20:23
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    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.

    Yours,
    Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 17 Mar 2020 13:50:32 -0400

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

---

From: Sander Steffann <[email-masked]>
Date: Tue, 17 Mar 2020 18:54:14 +0100

Hi,

> PSP avoids any routing header processing at the egress PE, as the quoted text above states. Hence the benefit.

What benefit?
Sander

PS:

Just because PSP removed a routing header doesn't mean the egress PE doesn't have to look for any remaining routing headers.

From 8200: "Each extension header should occur at most once…".
That is a should, not a must

And: "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet…"
That is a must, not a should.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 27 Mar 2020 16:24:44 +0000

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 <[email-masked]> 
Sent: martes, 17 de marzo de 2020 18:51
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
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:
> Subject: Re: [spring] Question on 
> draft-ietf-spring-srv6-network-programming-12
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Mar 2020 12:34:32 -0400

Thank you.  That is good enough to proceed regarding my concern.

Yours,
Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 27 Mar 2020 17:44:52 +0000

Thanks Joel. I have just posted a new version of the draft with those changes (rev15).

Cheers,
Pablo.

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: viernes, 27 de marzo de 2020 17:35
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Yours,
Joel

On 3/27/2020 12:24 PM, Pablo Camarillo (pcamaril) wrote:
> <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>
> 
> <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>
>    ...
> 
> 
> 
> 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
>