Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Ketan Talaulikar <[e-mail]>]

Hi Erik,

Could you please let us know if the updates posted to address comments from
other ADs also address your concerns? We would appreciate your feedback and
input on any further changes that may be required.

The latest version is:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13

Thanks,
Ketan


On Thu, Feb 17, 2022 at 1:49 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Erik,
>
> Thanks for your review and please check inline below for responses.
>
>
> On Thu, Feb 17, 2022 at 11:33 AM Erik Kline via Datatracker <
> [e-mail]> wrote:
>
>> Erik Kline has entered the following ballot position for
>> draft-ietf-bess-srv6-services-11: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I have little to add to the DISCUSSes held by others beyond my support.
>>
>> However, I would like to discuss having SRv6 control plane information,
>> i.e.
>> SIDs and their behaviours etc., being isolated by associating it with
>> a separate SAFI.  Any other protocol element that needs to refer to such
>> information can make reference to it through context-appropriate
>> extensions.
>>
>
> KT> This is what the draft proposes. We have existing BGP services (e.g.
> L3VPN & EVPN) and we are introducing extensions for signaling of SRv6
> specific context for them.
>
>
>>
>> {AFI=IPv6, SAFI=unicast} is a valid way to advertise an SRv6 locator
>> prefix,
>> for example, as that's just IPv6 forwarding information.  If SRv6-specific
>> information where separately advertised as {AFI=IPv6, SAFI=SRv6} then I
>> suspect it would be simpler to filter out that information, detect leaks,
>> and generally help the SRv6 domain fail closed more easily.
>>
>
> KT> This document does not cover nor discuss signaling of SRv6 locator
> prefixes. That is already done today by IGPs with or without summarization
> (or where necessary in multi-AS networks by BGP for IPv6 RFC 2545) and this
> is all within a provider network. Nothing new is required for that.
>
>
>> But I'm prepared to learn why this wouldn't work or would be somehow
>> worse.
>>
>
> KT> It isn't necessary nor required because SRv6 locators are just IPv6
> prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
> provider that uses global IPv6 addresses in their infrastructure (e.g. for
> their BGP and other routing sessions, on their router links and loopback,
> for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP.
> These are not advertised (nor leaked) out into the Internet since doing so
> can result in attacks on their internal network and infrastructure. They
> are protected via BGP configuration to stop leaks and then again by ACLs at
> Internet Border Routers to prevent attacks via the data path. This still
> remains the case to be done for SRv6 locators - they are similarly the
> service provider's "internal" infrastructure.
>
> Thanks,
> Ketan
>
>
>
>
>