> On Mar 12, 2020, at 6:06 AM, Pablo Camarillo (pcamaril)
> <pcamaril=40cisco....@dmarc.ietf.org> wrote:
>
> 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
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.
>
> 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 <cho...@chopps.org>
> Date: Wednesday, 11 March 2020 at 20:21
> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
> Cc: Christian Hopps <cho...@chopps.org>, "spring@ietf.org" <spring@ietf.org>
> Subject: Re: [spring] Question on
> draft-ietf-spring-srv6-network-programming-12
>
>
>
>> On Mar 11, 2020, at 2:44 PM, Pablo Camarillo (pcamaril) <pcama...@cisco.com>
>> wrote:
>>
>> 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.
>
> 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.
>
>>
>> Many thanks,
>> Pablo.
>>
>> -----Original Message-----
>> From: Christian Hopps <cho...@chopps.org>
>> Date: Wednesday, 11 March 2020 at 17:08
>> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
>> Cc: Christian Hopps <cho...@chopps.org>, "spring@ietf.org" <spring@ietf.org>
>> Subject: Re: [spring] Question on
>> draft-ietf-spring-srv6-network-programming-12
>>
>>
>>
>>> On Mar 11, 2020, at 8:16 AM, Pablo Camarillo (pcamaril)
>>> <pcamaril=40cisco....@dmarc.ietf.org> wrote:
>>>
>>> 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.
>>
>> 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.
>>
>>>
>>> Thank you,
>>> Pablo.
>>>
>>> -----Original Message-----
>>> From: Christian Hopps <cho...@chopps.org>
>>> Date: Wednesday, 11 March 2020 at 12:06
>>> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
>>> Cc: Christian Hopps <cho...@chopps.org>, "spring@ietf.org" <spring@ietf.org>
>>> Subject: Re: [spring] Question on
>>> draft-ietf-spring-srv6-network-programming-12
>>>
>>>
>>>
>>>> On Mar 11, 2020, at 5:59 AM, Pablo Camarillo (pcamaril)
>>>> <pcamaril=40cisco....@dmarc.ietf.org> 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.
>>>
>>>
>>>>
>>>> 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 <cho...@chopps.org>
>>>> Date: Tuesday, 10 March 2020 at 22:01
>>>> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
>>>> Cc: Christian Hopps <cho...@chopps.org>, "spring@ietf.org"
>>>> <spring@ietf.org>
>>>> Subject: Re: [spring] Question on
>>>> draft-ietf-spring-srv6-network-programming-12
>>>>
>>>>
>>>>
>>>>> On Mar 10, 2020, at 2:13 PM, Pablo Camarillo (pcamaril)
>>>>> <pcamaril=40cisco....@dmarc.ietf.org> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>>>
>>>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
