[OSPF] Fwd: OSPF Multi-Instance and Transport Instance

[Acee Lindem <[e-mail]>]

I believe we are now ready to take this AD sponsored work on and make  
these OSPF WG documents.
Thanks,
Acee

Begin forwarded message:

> From: Acee Lindem <[e-mail]>
> Date: February 27, 2009 11:58:44 AM EST
> To: PAPADIMITRIOU Dimitri <[e-mail]>
> Cc: OSPF List <[e-mail]>
> Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance
>
> Dimitri,
> See inline.
> On Feb 18, 2009, at 3:15 AM, PAPADIMITRIOU Dimitri wrote:
>
>> acee:
>>
>>> -----Original Message-----
>>> From: Acee Lindem [mailto:[e-mail]]
>>> Sent: Tuesday, February 17, 2009 4:06 PM
>>> To: PAPADIMITRIOU Dimitri
>>> Cc: OSPF List
>>> Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance
>>>
>>>
>>> On Feb 15, 2009, at 5:18 AM, PAPADIMITRIOU Dimitri wrote:
>>>
>>>>
>>>> pls, re-read your meeting minutes.
>>>>
>>>> The first issue is: fixed segmentation of resources between
>>> instances
>>>> processing non-opaque and opaque LSAs is less robust than a  
>>>> flexible
>>>> sharing of these resources assuming events triggering opaque and
>>>> non-opaque LSAs (used indirectly by some application) are
>>> independent.
>>>> The assumption of correlation (opaque LSAs directly
>>> processed by OSPF)
>>>> is left possible by RFC 2740. Nevertheless, this draft does not
>>>> isolate
>>>> the "IP Routing instance" from the latter LSAs.
>>>>
>>>> The second issue is: i) the proposal moves from multiplexed
>>>> exchanges to
>>>> serialized exchanges of LS PDUs between peering instances of
>>>> opaques and
>>>> non-opaque LSAs, ii) the messaging between different instances  
>>>> still
>>>> share the same links and header processing (note: by definition
>>>> instances are "co-located") but are under the control of different
>>>> instances thus requiring further prioritization at the sender side.
>>>> Thus, the current proposal further constraints the sender's
>>>> instances to
>>>> expectedly prevent overloading the receiver. This is made
>>> possible by
>>>> putting down to the OSPF header (instead of the LSA header) the
>>>> information with which prioritization at the sender would
>>> be possible.
>>>> Nevertheless, is that not strictly equivalent to prioritize
>>> on the LSA
>>>> header when the instances are common i.e. the draft adds an
>>> identifier
>>>> because it puts processing down the OSPF header. The result is not
>>>> different from what would be possible using the "Opaque Type" (in
>>>> combination with the LS Type) since it is only for a sub-class of
>>>> Opaque
>>>> LSA (those that are not directly processed by OSPF) that
>>> the issue of
>>>> overloading expectedly arises.
>>>
>>> Section 2.4 addresses IP/IPv6 packet prioritization and many (if not
>>> most) commercial routers use the packet precedence for internal
>>> prioritization. What more would be required? We could state that the
>>> precedence MAY also used for internal prioritization. However, we
>>> want to steer clear of implying a specific implementation.
>>
>> The point here is that this notion of "instance ID" is not meant to
>> solve any "overload" problem it is primarily a separation of  
>> instances
>> for administrative and policy reasons. Any of them are instances
>> exchanges LSAs and Opaque LSAs.
>>
>> In the present case, the problem - that i perfectly acknowledge - is
>> resulting from the dual use of Opaque LSAs wrt other LSA exchanges
>> whereas the instance ID does not assume such separation.
>
> I believe the OSPF instance provide a natural boundary to address this
> problem better than mechanisms within a protocol. Refer to section  
> 2.4.
>
> 2.4.  Network Prioritization
>
>    While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP
>    precedence Internetwork Control, any packets sent by a transport
>    instance will be sent with IP precedence Flash (B'011').  This is
>    only appropriate given that this is a pretty flashy mechanism.
>
>    Similarly, OSPFv3 transport instance packets will be sent with the
>    traffic class mapped to flash (B'011') as specified in ([OSPFV3].
>
>    By setting the IP/IPv6 precedence differently for OSPF transport
>    instance packets, normal OSPF routing instances can be given  
> priority
>    during both packet transmission and reception.  In fact, Some  
> router
>    implemenations map the IP precedence directly to their internal
>    packet priority.  However, implementation issues are beyond the  
> scope
>    of this document.
>
> Thanks,
> Acee
>
>
>
>>
>> Thanks,
>> -dimitri.
>>> Thanks,
>>> Acee
>>>
>>>
>>>>
>>>> -d.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>> Behalf Of Acee Lindem
>>>>> Sent: Saturday, February 14, 2009 10:44 PM
>>>>> To: OSPF List
>>>>> Subject: [OSPF] OSPF Multi-Instance and Transport Instance
>>>>>
>>>>> In Minneapolis, there was some interest in making these WG group
>>>>> documents. Additionally, the AD have sponsored this activity given
>>>>> that a solution is being actively pursued in the ISIS WG (though
>>>>> significantly less powerful).
>>>>>
>>>>> There was one dissenting comment that one could achieve the same
>>>>> results with a single instance given sufficient invention (aka,  
>>>>> the
>>>>> "even pigs can fly" argument). I've added text to the transport
>>>>> instance draft as well as mechanisms and text enabling sparse
>>>>> topologies that I believe clearly demonstrates the superiority of
>>>>> this solution. Hence, I like to now ask if there is any further
>>>>> reason not to make these WG documents?
>>>>>
>>>>> Here are the current versions:
>>>>>
>>>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-multi-
>>>>> instance-02.txt
>>>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-transport-
>>>>> instance-02.txt
>>>>>
>>>>> Thanks,
>>>>> Acee
>>>>> _______________________________________________
>>>>> OSPF mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>
>>>
>>>
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf