Hi Harish, > On Oct 17, 2024, at 03:39, Harish R Prabhu <[email protected]> wrote: > > Hi Acee/others, > > If we do not support multiple prefixes over the same link in OSPFv3, won't it > be a backward compatibility issue with OSPFv2? I believe OSPFv2 > implementations have supported per subnet interfaces (and also, you've > mentioned this in this thread earlier).
OSPFv3 readily supports multiple prefixes on the same link - although the link-local address is used as the source address for OSPF packets. What implementations have not supported is the specifications in section 4.9 of RFC 5340. You can put multiple OSPFv3 interfaces on the same physical interface and use the instance-id to differentiate them - section 4.9 deals with the situations where you use the same instance-id (e.g., 0) on multiple interfaces on the same link. > > Also, on broadcast interfaces the neighborship formation is per subnet, isn't > it? Yes. > So if I have multiple prefixes on an IPv6 'link', all the routers connected > to the link will automatically become neighbors. There may be ways to > circumvent this, but implementation could become kludgy. This is a pickle, > IMHO. Please let me know if this observation is valid. This is expected - as I stated before, OSPFv3 runs on a link, not a subnet. > > If yes, what would be the best way to mitigate this? If you don’t want them to be adjacent, just configure different instance-ids. Only OSPFv3 routers with the same configured instance-id will become adjacent. > An errata, may be? Though reading and understanding RFC 5340. I don’t think there is anything incorrect here. Hope this helps, Acee > > Best regards, > Harish R Prabhu > -- > Bangalore, India. > [email protected] <mailto:[email protected]> > > On Wed, Oct 16, 2024 at 7:51 PM Harish R Prabhu <[email protected] > <mailto:[email protected]>> wrote: >> Got it, thank you. It is clear from the ospf protocol point of view. >> Besr regards, >> Harish >> >> >> On Wed, 16 Oct, 2024, 7:35 pm Acee Lindem, <[email protected] >> <mailto:[email protected]>> wrote: >>> Hi Harish, >>> >>>> On Oct 16, 2024, at 08:11, Harish R Prabhu <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Thank gou, Acee. I did notice the interface instance ID which was >>>> mentioned in 5340 in the yang model. However, interface id was missing. >>>> >>> The interface id isn’t configured in OSPFv3. It is normally the ifIndex >>> which comes from the ietf-interfaces.yang YANG module (RFC 8343). >>> >>> From RFC 5340: >>> >>> Interface ID >>> Every interface is assigned an Interface ID, which uniquely >>> identifies the interface with the router. For example, some >>> implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) >>> as the Interface ID. The Interface ID appears in Hello packets >>> sent out the interface, the link-local-LSA originated by the >>> router for the attached link, and the router-LSA originated by the >>> router-LSA for the associated area. It will also serve as the >>> Link State ID for the network-LSA that the router will originate >>> for the link if the router is elected Designated Router. >>> The Interface ID for a virtual link is independent of the >>> Interface ID of the outgoing interface it traverses in the transit >>> area. >>> >>> It is included in ietf-ospf.yang (RFC 9129) but as operational state: >>> >>> leaf interface-id { >>> type uint32; >>> config false; >>> description >>> "OSPFv3 interface ID."; >>> } >>> } >>>> 5340 is clear about the protocol running on the link, rather than the >>>> interfaces. >>>> >>>> But in that case, what is ths context of multiple interfaces discussion in >>>> the RFC? An example use case will make it very clear to me. >>>> >>> This is putting multiple interfaces on the same network - I’m not aware of >>> anyone who has implemented this. I’d deprecate it if I ever respin RFC 5340 >>> as a Draft Standard. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> >>>> Best regards, >>>> Harish >>>> >>>> >>>> On Wed, 16 Oct, 2024, 3:42 pm Acee Lindem, <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>>> On Oct 16, 2024, at 01:39, Harish R Prabhu <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Hi experts, >>>>>> >>>>>> My question is with regards to the OSPF yang scheme. >>>>>> >>>>>> RFC 5340 allows configuring multiple interfaces on the same link. >>>>>> >>>>>> As per my understanding on a linux machine, >>>>>> >>>>>> eth0 can be a link >>>>>> IPv6 address A/B would be one interface >>>>>> IPv6 address C/D could be another interface. >>>>>> Is this understanding correct? >>>>>> >>>>>> If so, why can't I configure interfaces selectively on a link today? For >>>>>> example, I want only A/B to be part of OSPF routing, not the other one >>>>>> (using the above example).? The doubt arises because there is no address >>>>>> configuration parameter for OSPF interfaces. >>>>> >>>>> In OSPFv3, the protocol runs on the link and not a specific subnet. >>>>> >>>>> The instance ID is in the YANG model (RFC 9129). >>>>> >>>>> grouping ospfv3-interface-config { >>>>> description >>>>> "OSPFv3 interface-specific configuration state."; >>>>> >>>>> leaf instance-id { >>>>> type uint8; >>>>> default "0"; >>>>> description >>>>> "OSPFv3 instance ID."; >>>>> } >>>>> } >>>>> >>>>> Hope this helps, >>>>> Acee >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Also as per 5340 interface id, and interface instance id is required for >>>>>> supporting multiple interfaces. But i do not see interface id in the >>>>>> yang specification. >>>>>> >>>>>> What am I missing? Maybe these are already answered previously in the >>>>>> mailing list. Please bear with me, appreciate the patience and answers >>>>>> from the experts. >>>>>> >>>>>> Thanks, >>>>>> Harish >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Harish R Prabhu >>>>>> -- >>>>>> Bangalore, India. >>>>>> [email protected] >>>>>> <mailto:[email protected]>_______________________________________________ >>>>>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>>>>> To unsubscribe send an email to [email protected] >>>>>> <mailto:[email protected]> >>>>> >>>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
