Acee, Your explanation does clarify bow this can be done. Thank you again for a quick response.
Cheers, Harish On Thu, 17 Oct, 2024, 3:28 pm Acee Lindem, <[email protected]> wrote: > 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] > > > On Wed, Oct 16, 2024 at 7:51 PM Harish R Prabhu <[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]> wrote: >> >>> Hi Harish, >>> >>> On Oct 16, 2024, at 08:11, Harish R Prabhu <[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]> wrote: >>> >>>> >>>> >>>> On Oct 16, 2024, at 01:39, Harish R Prabhu <[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] >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>>> >>>> >>> >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
