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

[Warren Kumari <[e-mail]>]

On Tue, Dec 10, 2019 at 7:51 PM Brian E Carpenter
<[e-mail]> wrote:
>
> 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?
[ Of hats, I have none... ]

I think that not having RFC2119 language in this section is very
unfortunate, and creates a situation where different people read
different things into it (and are convinced that their interpretations
are clearly the right ones....)

I personally think that the spirit behind the Postel principle
applies, and that the should is a prohibition against there being more
than one, and that if receivers happen to do something sane in this
case, it is close to luck, not spec.

I'm not religious, but this seemed apropo:
"Then Abimelek called Abraham in and said, “What have you done to us?
How have I wronged you that you have brought such great guilt upon me
and my kingdom? You have done things to me that should never be done.”
- Genesis 20:9
:-P

W


>
> 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
> >> --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf