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

From: "Vivek Dubey" <[email-masked]>
Date: 9 Jun 2006 09:43:39 -0000

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.

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Fri, 09 Jun 2006 13:40:38 -0400

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

---

From: Paul Wells <[email-masked]>
Date: Fri, 09 Jun 2006 13:13:41 -0500

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.

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
>>
>>>> <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 ?
>>>>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 09 Jun 2006 14:21:22 -0400

Hi Paul,

Paul Wells wrote:

> 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".
>

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.

Thanks,
Acee

>>>>> <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 ?
>>>>>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 09 Jun 2006 14:46:23 -0400

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:

> I agree. The packet header term Instance ID is rather unfortunate but 
> I don't want to

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.  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

---

From: Paul Wells <[email-masked]>
Date: Fri, 09 Jun 2006 16:06:21 -0500

Hi Acee,

Acee Lindem wrote:
>          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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 09 Jun 2006 17:20:33 -0400

Hi Paul,

Paul Wells wrote:

>>> I agree. The packet header term Instance ID is rather unfortunate 
>>> but I don't want to

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

>>>>>> 3.2.2  Receiving protocol packets  The Instance ID specified in 
>>>>>> the OSPF header must match the receiving interface's Instance ID
>>>>>>
>>>>>>>> SNMP Community string (RFC 4133) concept would be used for 
>>>>>>>> tables not having instance id as part of index?
>>>>>>>>

---

From: Paul Wells <[email-masked]>
Date: Fri, 09 Jun 2006 17:23:30 -0500

Hi Acee,

>>> disucssion of support for multiple interfaces attached to the same link.

<snip>

> on intra-area prefix LSAs.

Are we talking about "physical" interfaces or interfaces as defined by 
an OSPF interface structure?  As it happens, I wrote the packet input 
code for an implementation that allows multiple OSPFv3 instances to 
share a physical interface, however in that case each OSPFv3 instance 
has it's own interface structure with a single instance ID value.

Thanks,
Paul

>>>      source address equal to one of the router's local addresses.

<snip>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 09 Jun 2006 18:38:22 -0400

Hi Paul,

> has it's own interface structure with a single instance ID value.

Ok - I see your point but it is semantics rather than functionality.
 I mean physical interface. I think if I change the text to say
"receiving link" it should be clear.

Thanks,