RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Sander,



Please check inline below.



-----Original Message-----
From: Sander Steffann <[e-mail]>
Sent: 12 March 2020 19:14
To: Ketan Talaulikar (ketant) <[e-mail]>
Cc: Andrew Alston <[e-mail]>; Pablo Camarillo (pcamaril) <[e-mail]>; [e-mail]; 6man WG <[e-mail]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming



Hi,



> In this context, we are talking about allocations for the provider's infrastructure.



No, we’re not. Allocations are the superblocks that RIRs delegate to an LIR. Before being allowed to use address space an LIR has to make assignments from that allocation. It is that assignment policy that seems incompatible with the way that net-pgm seems to use addresses.

[KT] I was talking about the allocation for use for SRv6 – that is for the provider’s infrastructure.

> > So what is it that you and Andrew see in the net-pgm draft or the SRv6 proposal that lead you to believe such a change in the IPv6 assignment or allocation sizes are required by RIRs?

>

> Well, your example mentions that a /40 is used for SRv6 in a very large setup. A regular business entity has a /48 and a regular ISP will have a /29 available.

> [KT] The example of /40 is for a large SP across their network infrastructure – not a single POP.



I understand. At least one RIR has a policy that doesn’t allow for assignments to network-side infrastructure, only assignments per PoP. I’m not saying this shouldn’t be fixed (I think this is an oversight), but this working group should be aware of that.



> I think it is necessary to look at what an expected address space requirements for SRv6 will be for such entities, and whether that fits and leaves enough remaining address space for the rest of the network.

> [KT] Sure and I would expect such discussions to happen at NOGs or in other operational forums including within the IETF.

>

> What is also necessary is to see if the way SRv6 uses addresses is compatible with the RIR policies. In the RIPE NCC region we havehttps://www.ripe.net/publications/docs/ripe-707#assignment_infra, which basically allows for a separate /48 per PoP and a single /48 for in-house operation of the operator. If changes are required in RIR policies their communities need to be told so, and mutual expectations of what will and will not be considered acceptable address space use will have to be discussed.

> [KT] I believe so and we should get the feedback and inputs of operators that have deployed or deploying it. AFAIK none of them have raised such a concern or any issue with the RIR policies.



That’s nice. I’m just making you and the rest of the working group aware of the incompatibilities that I have noticed. Apparently so far you have been lucky that you haven’t hit the limits of RIR policies yet, or that the operators have violated the RIR policy without realising it. This is why I am informing the WG of this potential issue that might need some work.

[KT] I think it is unfair to say that operators deploying SRv6 are not aware of their RIR’s policies and cannot be expected to perform their allocations appropriately. Coming to the net-pgm document itself, there are no incompatibilities – let me clarify in further comments what might be the source of this misconception.



> > I am assuming this is the same "IP Space burn" topic that Andrew alludes to …

>

> Yes

> [KT] Thanks for confirming. So this is then a discussion on how providers want to manage their address space and allocations within it for SRv6. Nothing prevents such a discussion from continuing. I just don’t see how this as being related to the progression of the net-pgm draft towards publication.



The draft introduces an new IPv6 address format, so I think it has to at least give guidelines on the expected use and the expected sizes of LOC (L), FUNCT (F) and ARG (A). Although 3.1 says "F and A may be any value as long as L+F+A <= 128” I noticed that 9.2 says "The range of the registry is 0-65535 (0x0000 - 0xFFFF)”. That places at least a minimum size limit on the length of F that should be reflected in 3.1. What I am missing completely are guidelines on the size of A that can be reasonably expected.

[KT] Seems like you might have the same misconception as few others had between “behavior code points” (in 9.2) and the “function bits” in the SIDs. Please check

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-13#section-9.2


   This
   sub-registry maintains 16-bit identifiers for the SRv6 Endpoint
   behaviors.  This registry is established to provide consistency for
   control plane protocols which need to refer to these behaviors.
   These values are not encoded in the function bits within a SID.





Concretely:

- Section 3.1 needs guidelines on the expected sizes of F and A, which will give operators guidance on the L they should assign to network programming

- Explicit guidance on the size of L would be greatly appreciated

- The guideline on the size of F should state that at least 16 bits are required (considering section 9.1). Whether the authors want to specify F==16 or F>=16 is up to them.

[KT] I think you are suggesting for the specification to be prescriptive when clearly it needs to be flexible as reflected in the draft text to allow operators the flexibility in managing allocations and assignments based on their use-cases and requirements (one of these factors would be what they have/get from their RIR). We can obviously continue discussions on this topic in the Spring WG (and possibly others related) and get feedback from operators and their deployments – that would lead to more meaningful guidance. I don’t think this standards track document is the right place for such a discussion.



Thanks,

Ketan



Cheers,

Sander