Re: [spring] 64-bit locators

[Gyan Mishra <[e-mail]>]

On Fri, Dec 27, 2019 at 5:45 PM Robert Raszuk <[e-mail]> wrote:

> Hi Mark,
>
> Happy New Year !
>
>
>> The key point is that RIDs look like IPv4 addresses, but are not. They
>> only have adopted the formatting convention of IPv4 addresses. They're 32
>> bit quantities. They could have just as easily been formatted as 0x hex
>> strings e.g. 0xffffffff for my example. Their continued use as 32 bit
>> quantities and identifiers in IPv6 supporting OSPFv3 shows how decoupled
>> from both IPv4 and IPv6 they are.
>>
>
> We are again in 100% agreement here. That was exactly my analogy to RID
> made to Ron. But on the other hand let's also recognize that this is pretty
> common to assign router_id to be yr loopback address in number of
> protocols.
>
>
>> SIDs on the other hand are at some point in time used as IPv6 destination
>> addresses.
>>
>
> Well SID locators (of variable length) need to assure packet delivery to a
> segment end points. That is a subtle but very important difference.
>
>
>> That means they have to either always comply with IPv6 address
>> requirements - RFC4291 - or be converted to meet IPv6 address requirements
>> when they're used as IPv6 addresses (e.g. they're 64 bit quantities that
>> are then used as an IPv6 Interface Identifier by prepending an IPv6
>> addressing compliant /64 prefix)
>>
>
> IPv6 address fields are 128 bits (for good or for bad of it). And there
> are no :: or : there to the point Alex made earlier. What matters is to
> make sure that routing prefixes deliver packets to correct destinations.
>
> I am very puzzled reading those messages what is the point regarding all
> remaining bits outside of locator ? If this is to say RFC4291 did not
> defined a SID - sure you won - game over. But at the same time I do not see
> anything in RFC4291 which would prohibit me to put any bit sequence I like
> in the remaining (least significant) bits of the address. And I think this
> is the crux of the little discussion here.
>
> Cheers,
> R.
>
> [Gyan] The router-id scenario is a good one to compare to this SID address
> format scenario. How   this scenario differs which is the crux is the
> router-id is not required to be routable, where the SID locator must be
> routable for traffic steering ; copying SID locator into the DA.
>

If the SID locator was not copied into the DA, and was not required to be
> routable,  it could have an abstract notation “non IPv6 hextet” format.
> However, the fact that the SID locator, locally significant on each SRv6
> node for hop by hop traffic steering ;  the SID has to be reachable via IGP
> within the SR domain.  The  SID locator  is in fact is an IPv6 address
> which I think cannot be disputed.
>

    So now any formatting of the SID however that maybe for
{locator;func;arg} must be updated in RFC 4291 to start and all other
related RFCs that define the IPv6 formatting.  As far as our current IPv6
addressing standards SLAAC defines a strict /64 bit boundary where DHCPv6
and manual IPv6 assignment does not have the /64 boundary and support VLSM.


So at the beginning of this discussion was mentioned keeping the 3 SID
fields fixed or variable.

So since there are 3 fields and not 2 fields, the SID format  does not fall
in the current IPv6 addressing architecture made up of 2 fields for slaac
64 bit boundary or no discrete fields for vlsm.  There are protocols that
use the bits within the IID for IPv4/IPv6 translators RFC 6144 used for
NAT64 for example.  This case with SRv6 the major issue is that with the 3
fields it does not fall in any currently defined addressing formats.
That’s the issue.

SRv6 is the first protocol where there are 3 fields defined that requires
an IPv6 address notation.

I think what is really need is the explicit definition of bits for each of
the 3 fields and update all IPv6 addressing  specs starting with RFC 4291.



>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant