RE: Extension Header Insertion

[Ron Bonica <[e-mail]>]

Brian,

When a protocol specification ignores a "should" recommendation , it SHOULD provide justification for doing so. Otherwise, the "should"  recommendationis meaningless.

Over the years, I have seen the following types of justification:

- Necessary: It is not possible to implement this protocol while conforming to the recommendation.
- Necessary optimization: It is not possible to make this protocol perform acceptably while conforming to the recommendation.
- Necessary simplification: It is not possible to operate and debug this protocol while conforming to the recommendation
- Unacceptable: I am ignoring this recommendation without offering any justification.

                                                              Ron



Juniper Business Use Only

-----Original Message-----
From: Brian E Carpenter <[e-mail]> 
Sent: Monday, December 9, 2019 8:02 PM
To: [e-mail]; Ron Bonica <[e-mail]>; '6man' <[e-mail]>
Subject: Re: Extension Header Insertion

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 <[e-mail]> *On Behalf Of *Ron Bonica
> *Sent:* 09 December 2019 03:04
> *To:* 6man <[e-mail]>
> *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
> [e-mail]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!VVSnZbHvCIx_b38GQZlY56-9iDtMPmXOpRPtPMb01i3KNpg23G-0z
> JIjIsiGNEzd$
> --------------------------------------------------------------------
>