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

[Paul Wells <[e-mail]>]

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.

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