My apologies for raising something that might have already been discussed a
rejected, but I'm finding it non-trivial to track this wide-ranging
discussion across multiple mailing lists.
Regardless of how SRv6 works now (using header insertion, as Darren said in
Singapore), I'm wondering if it would suffice to say that the ingress
encapsulation node could/should pad the SRH with an operationally
determined amount of extra space to allow for header re-writing.
This would effectively turn the SRH into a scratch space could be specified
as able to be re-written by SR-aware nodes along the path.
For example, if the ingress router new the SR domain's carefully curated
path MTU, it could pad out the SRH to some fraction of that, a la:
{segments_left=2, last_entry=5, [sr_rtr_3, sr_rtr_2, sr_rtr_1, ::0,
::0, ::0]}
then permit intermediate SR routers to rewrite all of that scratch space
for router insertion/deletion as needed. For example, if sr_rtr_1 needs to
route around sr_rtr_2 via sr_rtr_4 and sr_rtr_5 it could rewrite this as:
{segments_left=2, last_entry=5, [sr_rtr_3, sr_rtr_5, sr_rtr_4,
sr_rtr_1, ::0, ::0]}
If there's no scratch space left with which to fiddle then generate an ICMP
error to the ingress router (ICMP source address selection aside). The
rules for examining this header scratch space in the returned ICMP error
might need to be suitably lax.
I'm unsure of how this would interact with the HMAC bits, but overall, if
this could work then perhaps we don't need to worry about insertion anymore.
Yes, there's more overhead on each packet, but that should be tunable by
the operator based on things like (1) operational path mtu in the SR
domain, (2) operationally acceptable padding overhead, (3) expected space
required for adding routers for re-routing or whatever...
On Tue, Dec 10, 2019 at 11:45 AM Robert Raszuk <rob...@raszuk.net> wrote:
> Brian,
>
> > Situation has changed since this email: the network programming draft
>> has now removed text related to SRH insertion.
>> > Please comment on the text if you see text related to SRH insertion.
>>
>> For example:
>>
>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-8.2
>>
>> Why would draft-voyer-6man-extension-header-insertion exists if the SRH
>> proponents do not intend to perform SRH insertion?
>>
>
>
> What Bruno is describing is the new situation after removal of SRH
> insertion at non SR midpoints from NP draft under last call..
>
> Section 8.2 is referring to SRH insertion at the SR encapsulation node
> (for example ingress to the domain).
>
> draft-voyer-6man-extension-header-insertion is progressing as recommended
> to relax the RFC8200 restricting EH insertion at any arbitrary node - not
> necessarily segment endpoint.
>
> Regards,
> R.
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
