Re: [OSPF] Re: OSPFv3: Vlink Instance Id

[Acee Lindem <[e-mail]>]

Hi Paul,

Paul Wells wrote:

> Hi Acee,
>
> Acee Lindem wrote:
>
>> Paul, Vivek,
>>
>> Here is the suggested text. Note that I also moved
>> the local source address checking under OSPF processing to match the
>> disucssion of support for multiple interfaces attached to the same link.
>>
>> Thanks,
>> Acee
>>
>> Acee Lindem wrote:
>>
>>> Hi Paul,
>>>
>>> Paul Wells wrote:
>>>
>>>> Hi Acee,
>>>>
>>>> I think the problem is that we overload the term "instance".
>>>>
>>>> As I see it, the OSPFv3 instance ID is simply an attribute which is 
>>>> used to demux packets.  It could just as well have been called 
>>>> something like "OSPFv3 channel ID".
>>>>
>>>> This is not the same thing as the concept of multiple independent 
>>>> instances of OSPF running on the same router.
>>>
>>>
>>>
>>> I agree. The packet header term Instance ID is rather unfortunate 
>>> but I don't want to
>>> change it now given that it is in everybody's ospfv3 packet format 
>>> header file :^)
>>> I've tried to generalized the demux'ing without specifying the exact 
>>> implementation.
>>> I'll post the text snipet for comment ahead of the -10 version.
>>
>>
>> o  The Area ID and Instance ID found in the OSPF header must be
>>      verified.  If both of the following cases fail, the packet should
>>      be discarded.  The Area ID and Instance ID specified in the  header
>>      must either:
>>
>>
>>      1.  Match one of the Area ID(s) and Instance ID(s) for the
>>          receiving interface.  
>
>
> While I agree with the sentiment, can we really imply here that an 
> interface can have multiple Area IDs and/or Instance IDs? 
> Notwithstanding draft-ietf-ospf-multi-area-adj and 
> draft-ietf-ospf-af-alt there are a number of other places in the 
> existing RFCs that contradict this.

I think this was one (if not the primary) motivation for the OSPFv3
interface instance ID. I realize not all implementations support it but I
know of at least one that does. If I remember correctly, there is also
some additional code (I mean text) that needs to be added to the section
on intra-area prefix LSAs.

Thanks,
Acee


>
> Thanks,
> Paul
>
>>          Unlike IPv4, the IPv6 source address is
>>          not restricted to lie within the same IPv6 subnet as the
>>          receiving interface.  IPv6 OSPF runs per-link instead of per-
>>          IP-subnet.
>>
>>      2.  Match the backbone area and other criteria for a configured
>>          virtual link.  The receiving router must be an ABR (Area
>>          Border Router) and the Router ID specified in the packet (the
>>          source router) must be the other end of a configured virtual
>>          link.  Additionally, The receiving interface must attach to
>>          the virtual link's configured transit area and the  Instance ID
>>          must match the virtual link's Instance ID.  If all of these
>>          checks succeed, the packet is accepted and is from now on
>>          associated with the virtual link (and the backbone area).
>>
>>   o  Locally originated packets SHOULD NOT be processed by OSPF except
>>      for support of multiple interfaces attached to the same link as
>>      described in Section 3.9.  Locally originated packets have a
>>      source address equal to one of the router's local addresses.
>>
>> Thanks,
>> Acee
>>
>>
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>> Acee Lindem wrote:
>>>>
>>>>> Vivek Dubey wrote:
>>>>>
>>>>>> Hi Acee,
>>>>>>
>>>>>> Ospfv6 Draft 9
>>>>>> --------------
>>>>>> 3.2.2  Receiving protocol packets  The Instance ID specified in 
>>>>>> the OSPF header must match the receiving interface's Instance ID
>>>>>>
>>>>>> <vivek> Above check can than be done just after checking Ospf 
>>>>>> Version number being 3.
>>>>>>  
>>>>>>
>>>>> Hi Vivek,
>>>>>
>>>>> While the Instance ID can be used to allow the interface to be 
>>>>> configured
>>>>> in multiple OSPFv3 instances, it can also be used to allow the 
>>>>> interface to
>>>>> be configured in multiple areas in within the same OSPFv3 instance.
>>>>>
>>>>> I'll need to think more about updating the text.
>>>>>
>>>>> Thanks,
>>>>> Acee
>>>>>
>>>>>
>>>>>> Thanks
>>>>>> Vivek
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 08 Jun 2006 Acee Lindem wrote :
>>>>>>  
>>>>>>
>>>>>>> Hi Vivek,
>>>>>>> Ok - I see what you mean. The text was suppose to reference
>>>>>>> "Interface ID" rather than "Instance ID". I've corrected this 
>>>>>>> and moved
>>>>>>> it in the -10 version.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Acee
>>>>>>>
>>>>>>> Vivek Dubey wrote:
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>> Hi Acee,
>>>>>>>>
>>>>>>>> Consider the topology:
>>>>>>>>                                          
>>>>>>>> ---------(i0)R1(i1)------(i1)R2(i0)-----------
>>>>>>>>
>>>>>>>> Ospf Instance 1 configuration (Ospf-domain-1)
>>>>>>>> -----------------------------------------------
>>>>>>>> Router R1:
>>>>>>>> ----------
>>>>>>>> Interface i0: assocciated instance ID 1, Area 2.2.2.2
>>>>>>>> Interface i1: assocciated instance ID 1, Area 1.1.1.1
>>>>>>>> Vlink: Transit area 1.1.1.1, Nbr Rtr ID R2, ospfv3VirtIfInstId 2
>>>>>>>>
>>>>>>>>
>>>>>>>> Router R2:
>>>>>>>> ----------
>>>>>>>> Interface i0: assocciated instance ID 1, Area 0.0.0.0
>>>>>>>> Interface i1: assocciated instance ID 1, Area 1.1.1.1
>>>>>>>> Vlink: Transit area 1.1.1.1, Nbr Rtr ID R1, ospfv3VirtIfInstId 2
>>>>>>>>
>>>>>>>> <vivek1> Should this Vlink be made up, though the instance ID 
>>>>>>>> associated with Vlink is different than that of the physical 
>>>>>>>> interface, it would use.
>>>>>>>>
>>>>>>>> <vivek2> If VLink is declared up, it is part of Ospf-domain-2 
>>>>>>>> while rest of the interfaces are part of Ospf-domain-1. What 
>>>>>>>> purpose such a Vlink is accomplishing ?
>>>>>>>>
>>>>>>>> <vivek3> MIB configuration for tables:
>>>>>>>> Area Table
>>>>>>>> Area-Scope LSDB
>>>>>>>> AS-Scope  LSDB
>>>>>>>> Host Table
>>>>>>>> Do not provide support for Ospf Multiple Instances
>>>>>>>>
>>>>>>>> But for few other table:
>>>>>>>> Interface Table,
>>>>>>>> Link Scope LSDB
>>>>>>>> Explicit support of multiple instances is provided by making 
>>>>>>>> instance part of Index.
>>>>>>>>
>>>>>>>> SNMP Community string (RFC 4133) concept would be used for 
>>>>>>>> tables not having instance id as part of index?
>>>>>>>>
>>>>>>>> If so, why to make instance id as part of index for any table?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Vivek
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>  
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OSPF mailing list
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ospf
>
>

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf