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

[Brian E Carpenter <[e-mail]>]

Thanks Darren. I will hold off on the spring draft until we see a new version, since several of us are simply repeating ourselves at this point.

On balance I'm inclined to point a finger at RFC8200:

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

I now think that either that "should" should be a "must", or there
should be an explicit statement that only one routing header is
allowed. The complexities of multiple routing headers are endless.

What do others think?

Regards
   Brian Carpenter

On 11-Dec-19 11:04, Darren Dukes (ddukes) wrote:
> Hi Brian.  
> 
> I do believe that “assumption” you mention in draft-ietf-spring-network-programming is to be removed as a result of the last call discussion on spring@.
> 
> As I mentioned in a separate thread, RFC8200 states "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times”, the ‘assumption’ could been seen as a reminder of that requirement, but I don’t think thats necessary either.
> 
> There is no draft adopted by SPRING nor 6MAN that proposes multiple SRH be added to a packet.
> 
> If 6MAN intends to adopt a standards track definition of SRH insertion, then that document would need to fully describe the possible ramifications, including this one.  This we know, and are having much lively discussion on it.  I think we are safe to never have it ’sneak in’ without 6man having a say :)
> 
> Darren
> 
>> On Dec 10, 2019, at 2:27 PM, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Hi Fernando,
>>
>> On 10-Dec-19 21:39, Fernando Gont wrote:
>>> Hi, Brian,
>>>
>>> On 9/12/19 20:21, Brian E Carpenter wrote:
>>>> So, let's assume that two consecutive SRH headers are allowed in the same packet.
>>>
>>> Part of the problem with all these discussions is that folks seem to
>>> assume that there is no rationale for the existing rules, and they
>>> insist on changing them without providing any analysis/rationale.
>>>
>>> RFC8200 contains what should be considered a recommendation (at the very
>>> least) against multiple routing headers.
>>>
>>>
>>> A RH is meant to convey some sort of information about the path that a
>>> packet can traverse. So two SRHs would mean that the same packet should
>>> follow two different paths, at the same time. That doesn't seem to be
>>> much sense to me.
>>
>> I agree. That's why I am seriously asking whether we should recall
>> draft-ietf-6man-segment-routing-header-26 from the RFC Editor in order
>> to resolve this. Either (a) there MUST be at most one SRH in a packet,
>> or (b) the semantics and conflict resolution for multiple SRHs need to
>> be specified.
>>
>> At the moment we (6MAN) are on track to publish a Proposed Standard RFC
>> that leaves this ambiguous, and SPRING has a draft in WGLC that assumes (b).
>>
>>   Brian
>>
>>>
>>>
>>>
>>>> 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?
>>>
>>> It is clearly recommended against.
>>>
>>> However, the very draft-voyer-6man-extension-header-insertion doesn't
>>> even provide a rationale for EH insertion in the first place, let alone
>>> for this specific case that you (reasonably) raise.
>>>
>>> Unfortunately, when operating in a mode where analysis is discoraged,
>>> and "why?" questions are dismissed, I'm not sure there is any other
>>> possible alternative outcome than this -- documents with lots of
>>> unspecified stuff, violating specs at will, and designs try to cover up
>>> what seem to be sub-optimal design choices (like using 128-bit labels
>>> for what are expected/supposed to be limited domains) by screwing up the
>>> architecture to save bytes that were wasted elsewhere.
>>>
>>> Thanks,
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail] <mailto:[e-mail]>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>