Dimitri,
See inline.
On Feb 18, 2009, at 3:15 AM, PAPADIMITRIOU Dimitri wrote:
acee:
-----Original Message-----
From: Acee Lindem [mailto:a...@redback.com]
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: ospf-boun...@ietf.org [mailto:ospf-boun...@ietf.org] 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
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
