Chris,
please see inline:
On 23/03/2020 17:39, Chris Bowers wrote:
Peter,
The proposed SRv6 SID Structure Sub-Sub-TLV has several problems.
1) As discussed in item#3 below, it is not clear that flooding LB
Length, LN Length, Fun. Length, and Arg. Length to all ISIS speakers is
really the right approach. However, if the WG determines that it is the
right approach, the current encodings of this information in the
proposed SRv6 SID Structure Sub-Sub-TLV are problematic. As discussed
earlier in this thread, a network operator may choose to not allocate
all locators from a single block, so LB Length and LN Length may not be
well-defined.
I'm not sure what do you mean by not "well defined". For every SID you
need to know the LOC (B+N) part. If you guarantee that it is the same on
all nodes, you know it from the local config, otherwise, you advertise
it with a SID.
The current encoding of the SRv6 SID Structure
Sub-Sub-TLV makes it difficult to represent this situation. The simple
thing to do for nodes that don't have a well-defined value of LB Length
and LN Length would be to not advertise a value for LB Length and LN
Length. However, since the currently proposed SRv6 SID Structure
Sub-Sub-TLV combines LB Length, LN Length, Fun. Length, and Arg. Length
into a single sub-sub-TLV, if a node wants to advertise values for Fun.
Length and Arg. Length, it also has to advertise values for LB Length
and LN Length. It seems like a better approach would be to have
different sub-sub-TLVs, one for LB Length and LN Length, and a separate
one for Fun. Length and Arg. Length to be able to better represent this
situation.
I'm afraid you are missing an important point.
SRv6 SID is defined as LOC:FUNCT:ARG, where LOC is represented as B:N.
To be able to find out where the func and arg are located, you need to
know the LOC length, e.g. Block and Node length. Advertising just Func
and Arg length does not help.
2) Now consider the situation where a network operator chooses to
allocate all locators from a single block, so that LB Length and LN
Length are well-defined across the network. A given node should
presumably advertise its own understanding of LB Length and LN Length.
A given node's understanding of LB Length and LN Length is a property of
the node. It is not a property of a given End SID. The currently
proposed SRv6 SID Structure Sub-Sub-TLV however is carried within each
End SID Sub-TLV. With the currently proposed encoding, presumably an
implementation is expected to send the exact same values of LB Length
and LN Length for all of the End SIDs that it advertises. Not only is
this inefficient, but it creates the need for logic to decide what to do
when different End SIDs advertised by the same node carry different
values of LB Length and LN Length in their sub-sub-TLVs. It seems like
a better approach would be for a given node to advertise its
understanding of the value of LB Length and LN Length in a sub-TLV of
the Router Capability TLV.
When we design the encoding, we have to define it such, that it supports
all possible use cases. We can not design the encoding that works for
single use case (allocate all locators from a single block) and does not
work for others - different block from different node, multiple blocks
on a single node (e.g. border node), which are all valid.
3) At this point, the only use case that has been proposed for flooding
the LB Length, LN Length, Fun. Length, and Arg. Length to all ISIS
speakers is to make it more convenient for BGP-LS to get those values to
an external controller as part of a topology feed from any ISIS node.
No use case has been proposed for ISIS speakers themselves to make use
of the information. It seems like a more scalable approach would be to
use BGP-LS sessions to collect the information from the subset of nodes
that actually produce the relevant information. So far there are no End
SIDs defined that are advertised in ISIS that have a non-zero Arg.
Length. If an End SID with non-zero Arg. Length were to be proposed in
the future as needing to be flooded to all ISIS nodes, it seems likely
that the new End SID would also be advertised using the BGP IP/VPN/EVPN
control plane. So it seems like a viable alternative for this
hypothetical future End SID would be to have the subset of nodes that
have non-zero Arg. Length values communicate to an external controller
via BGP sessions. I think the WG needs a more detailed discussion of a
concrete use case in order to determine whether flooding LB Length, LN
Length, Fun. Length, and Arg. Length to all ISIS speakers is really the
right approach.
there are networks, where BGP is not deployed on all nodes, only on a
few nodes that re-distribute the information to BGP-LS. In such case we
need the IGP to distribute this data.
Argument that "it seems likely that the new End SID would also be
advertised using the BGP IP/VPN/EV
