RE: What if? [was Re: Extension Header Insertion]

Folks,

Adding to Brian's question, assume that the SR ingress node creates a packet that contains an SRH. In  that SRH,

- SL[0] : Locator is Node A and function is END.DT4. The ARG cause the packet to be forwarded into VPN RED.
- SL[1] : Locator is Node B and  function is END

Node B inserts another SRH before the original SRH. In that SRH:

- SL[0] : Locator is Node D and function is END.DT4. The ARG cause the packet to be forwarded into VPN BLUE.
- SL[1] : : Locator is Node E and function is END

In this case, the second SRH contradicts the first by causing the packet to be forwarded into a different VPN. Which SRH takes priority?

                                                                                    Ron

Juniper Business Use Only

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com> 
Sent: Monday, December 9, 2019 8:21 PM
To: adrian@olddog.co.uk; Ron Bonica <rbonica@juniper.net>; '6man' <6man@ietf.org>
Subject: What if? [was Re: Extension Header Insertion]

So, let's assume that two consecutive SRH headers are allowed in the same packet.

So the first one (an example from draft-ietf-6man-segment-routing-header-26) is:

       Segments Left=2
       Last Entry=2
       Flags=0
       Tag=0
       Segment List[0]=S3
       Segment List[1]=S2
       Segment List[2]=S1

and the second one is

       Segments Left=1
       Last Entry=1
       Flags=0
       Tag=0
       Segment List[0]=S4
       Segment List[1]=S5

I made that up and it's obviously nonsense, but if this is allowed why aren't the rules for processing conflicting SRHs described in draft-ietf-6man-segment-routing-header-26? Do we need to recall it from the RFC Editor queue to be fixed?

Regards
   Brian Carpenter

On 10-Dec-19 14:02, Brian E Carpenter wrote:
> On 09-Dec-19 22:33, Adrian Farrel wrote:
>> Hi Ron,
>>
>> I think we can jump to a quick answer on this because draft-ietf-spring-srv6-network-programming-05 says:
>>
>>    We assume that the SRH may
>>    be present multiple times inside each packet.
>>
>> Thus we may assume that the proponents of Extension Header insertion do think that it is acceptable to insert a second routing header into a packet that already has one.
>>
>> And 8200 is clear when it says:
>>    Each extension header should occur at most once, except for the
>>    Destination Options header, which should occur at most twice (once
>>    before a Routing header and once before the upper-layer header).
> 
> That's "should", which in a non-RFC2119 document like RFC 8200, means "should".
> It's not "must". So while I would prefer that the relevant SRH 
> document justifies the exception, there isn't a breach of a mandatory requirement.
>   
>> So draft-ietf-spring-srv6-network-programming-05 includes a false assumption which need to be either removed or secured through an update to 8200.
>>  
>> Ideally, I suppose, draft-ietf-6man-segment-routing-header would have 
>> contained the clarification that the SRH could be present multiple 
>> times
> 
> Yes
> 
>> (updating 8200 as it went).
> 
> Unnecessary, IMHO.
> 
>     Brian
> 
>>
>>  
>>
>> Cheers,
>>
>> Adrian
>>
>>  
>>
>> *From:*ipv6 <ipv6-bounces@ietf.org> *On Behalf Of *Ron Bonica
>> *Sent:* 09 December 2019 03:04
>> *To:* 6man <6man@ietf.org>
>> *Subject:* Extension Header Insertion
>>
>>  
>>
>> Folks,
>>
>>  
>>
>> This question is posed primarily to the proponents of Extension Header insertion.
>>
>>  
>>
>> Do you think that it is acceptable to insert a second routing header into a packet that already has one, so the resulting packet looks like the following:
>>
>>  
>>
>>   * IPv6 header
>>   * SRH
>>   * SRH
>>   * Upper-layer header
>>
>>  
>>
>> Would this be common in TI-LFA?
>>
>>  
>>
>>                                                                       
>> Ron
>>
>>  
>>
>>  
>>
>> Juniper Business Use Only
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv
>> 6__;!!NEt6yMaO-gk!QcxrCDx88HILxijExwq_3hhEqP955MgFkB_g5T4Bb4T_FuZjRvj
>> 4jdITZ69rOB93$
>> --------------------------------------------------------------------
>>
> 