On Fri, Dec 27, 2019 at 5:45 PM Robert Raszuk <rob...@raszuk.net> 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
> spring@ietf.org
> 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: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/networking-technologies-consultant
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
