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

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

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,
>