On Tue, Dec 10, 2019 at 12:18 PM Robert Raszuk <rob...@raszuk.net> wrote:
> Hi Erik,
>
> What you are proposing IMHO is not needed.
>
> Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so
> is already doing an insertion of new SRH while maintaining src address and
> previous SRH content (modulo updating it). That is legally permitted
> operation based on IPv6 tunneling RFC.
>
> The word insertion has been questioned in the context of adding SRH at non
> SR midpoints (say for TI-LFA) into existing "private" IPv6 header. For this
> sure one could think of more structure (bypass section) of original SRH
> already present or addition of 2nd SRH.
>
If there were no resolution to the insertion question vis a vis RFC 8200,
then would it then suffice to recommend that ingress nodes should include
some padding for these non-SR midpoints to play with (iff. the network has
such midpoints), and otherwise abide by RFC 8200?
Thx
> R.
>
>
>
>
>
>
> On Tue, Dec 10, 2019 at 9:10 PM Erik Kline <ek.i...@gmail.com> wrote:
>
>> 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
>>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
