Thanks,
Igor
----- Original Message -----
From: "JP Vasseur" <jvasseur@cisco.com>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: <dpapadimitriou@psg.com>; <dimitri.papadimitriou@alcatel.be>;
"Adrian
Farrel" <adrian@olddog.co.uk>; "LE ROUX Jean-Louis RD-CORE-LAN"
<jeanlouis.leroux@francetelecom.com>; <ccamp@ops.ietf.org>
Sent: Monday, November 21, 2005 11:36 AM
Subject: Re: IGP Extensions - CCAMP Milestones
Hi Igor,
On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote:
Hi JP,
See in-line.
Cheers,
Igor
----- Original Message -----
From: "JP Vasseur" <jvasseur@cisco.com>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: <dpapadimitriou@psg.com>; <dimitri.papadimitriou@alcatel.be>;
"Adrian
Farrel" <adrian@olddog.co.uk>; "LE ROUX Jean-Louis RD-CORE-LAN"
<jeanlouis.leroux@francetelecom.com>; <ccamp@ops.ietf.org>
Sent: Sunday, November 20, 2005 9:57 AM
Subject: Re: IGP Extensions - CCAMP Milestones
Hi Igor,
On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote:
Hi everybody,
I'd like to note that although the AS scope flooding is allowed for
opaque
LSAs, in my experience it does not work.
So your experience is different than the one of many people ...
Opaque LSA have been
used for quite a few years without any problem. See RFC2370 (July
1998)
Imagine that some routing
controller advertises an AS scope LSA and goes out of service
quickly after
that. Controllers outside of the area that the dead controller
belongs to
have no way of detecting its death and, therefore, will keep using
the
advertising for another 90 min before the LSA times out.
I guess that you mean 60 min (Maxage=60mn, Architectural Constant) -
See RFC2328, but this is not the point, see below.
Note that the
controllers located within the same area do not have such a problem
because
they can always verify the validity of the advertising by trying to
locate a
sequence of active adjacencies interconnecting each of them with the
advertising controller. If they find at least one such a sequence,
the
advertising is valid (otherwise, it would be withdrawn); on the
other hand,
if no such sequences exist, than advertising is likely to be stale
and hence
could not be trusted. The conclusion is that opaque LSAs should
never be
flooded within AS, rather, within a single area, and, if there is a
need for
the information to be propagated beyond the area boundaries, ABRs
must relay
the advertising into other areas (by originating new area-scope
LSAs). Note
also that as far as I remember OSPF itself never uses AS scope
advertisings
for its own needs. For example, an ASBR does not distribute
external routes
learned by BGP from other ASs using AS scope LSAs, rather, the
routes are
advertised within a single area and ABRs relay the advertisings
into other
areas.
This is not correct. External routes are redistributed with LSA Type
5 which are
flooded across the entire domain except in stub-area (not
generated by
the ABR as type 3 as you mention).
IB>> True, that what is written in RFC2328.
well not just written in the RFC but implemented and deployed in OSPF
networks for years.
And my contention here is that
if an ASBR advertises LSAs type 5 and dies after that, than OSPF
speakers
outside of the ASBR's area have good likelihood to use stale
external routes
for a considerable period of time. There is no remedy to that (OSPF
speakers
do not use Keep Alive protocol :=). This, however, could be fixed by
avoiding using of AS scope flooding, and that's exactly the reason
why some
OSPF applications that I know of do just that. But this is the
discussion
for OSPF WG, I suggest not argue about that. See below.
There is nothing to fix here. Anyway, see below ...
Anyway, back to the point, one cannot say of course that "Opaque LSA
Type 11 does not work". There are suitable to some application,
this is
all. You can perfectly reply on an opaque LSA Type 11 to learn the
capability of a router which does not reside in the local area and
rely
on another mechanism to detect its liveness. There are several such
examples.
IB>> Let's stick to your example. Why is it better to flood router
capability LSAs across an AS, rather than flood them within a
single area
and have ABRs relay the advertisings into other areas by
originating their
own LSAs? Yes, the AS-scope flooding is simpler.
But what I am suggesting
has the following advantages:
a) Advertisings of a crashed LSR could be withdrawn from use
by all AS
LSRs immediately after the crash;
b) Advertisings could be summarized by an ABR providing
scalability
improvements;
OSPF provides an efficient way to flood information across the entire
routing domain: opaque LSA Type 11. If the use of such LSA is useful
to some applications why not using it ?
You highlight two aspects here
- Liveness of the capability advertising router: just rely on a
liveness protocol if you need to quickly detect a crash of the router
- Scalability improvement: this is in fact the opposite ... Think of
the extra work required on the ABR to leak TLV in other areas
compared to flood a Type 11 LSA. Apparently you do not appreciate the
architectural change that this would mean on OSPF.
c) What is more important that policies could be applied on
ABRs wrt to
what information is leaked to external areas. Regretfully, you keep
forgetting about the policy aspects, but in the context of AS-scope
flooding
how can you enforce that an LSR capabilities are advertised into
some areas,
not advertised into some other areas, and advertised in a modified
way into
the third set of areas?
Policy is of the utmost importance in many contexts such as Inter-AS/
Providers ... not sure the case of inter-area within a single AS is
the case. Now, if you want to propose a new mode of operation for
OSPF, you may want to discuss it with the OSPF WG ... We could
continue the discussion there ... since it belongs to OSPF.
JP.
Igor
Hope this helps.
JP.
The bottom line is that the TLVs described in the draft should be
of the
area scope (just like TE LSAs), and hence it is not all that
important
whether we use new high level TLVs or sub-TLVs of the TE router cap
TLV.
Igor
----- Original Message -----
From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "LE ROUX Jean-Louis RD-CORE-LAN"
<jeanlouis.leroux@francetelecom.com>;
"JP Vasseur" <jvasseur@cisco.com>; "Dimitri Papadimitriou"
<dimitri.papadimitriou@alcatel.be>; <ccamp@ops.ietf.org>
Sent: Friday, November 18, 2005 10:57 AM
Subject: Re: IGP Extensions - CCAMP Milestones
adrian
i think JL's reply did partially translate the initial concern
in brief, there are three well identified TE applications that
could
make use of the TE node cap TLVs on both intra and inter-area
basis:
- LSP Stitching edge node capability
- Edge nodes connecting/being P2MP TE egresses
- TE auto-mesh
hence, the question on why keeping separated TLVs as part of the
router
capability and not consider these as sub-TLVs of the TE router cap
TLV
this would
1) provide a logical grouping of TE sub-TLVs as part of the same
TLV and
2) leave the flexibility of flooding scope on a per application
need -
note: that the path computation specific sub-TLVs could still be
restricted with their current area-scope
hope this clarifies the issue,
thanks,
- dimitri.
Adrian Farrel wrote:
If I understand the question it is...
In draft-ietf-ospf-cap-07.txt introduces the OSPF router
information LSA
and states that this LSA may have type 9, 10 or 11 scope.
In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node
Capability
Descriptor) is added to the OSPF router information LSA. This TLV
(when
generated) MUST be advertised with type 10 scope. JL has given the
reason
why this is limited to type 10. This reason is, of course, open
for
discussion as he says.
In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-
GROUP) is
added
to the OSPF router information LSA. It states that the LSA may be
advertised with type 10 or type 11 scope. JP has given a reason
why you
might want type 11 in addition to type 10. This reason is, of
course,
open
for discussion.
An interesting feature is that a router advertising an AS-wide
mesh
group
*and* a TE router capability may require that two OSPF router
information
LSAs are advertised by the router.
The language in draft-ietf-ospf-cap-07.txt leans towards a router
sending
*an* OSPF router information LSA. But nowhere does it say that the
router
cannot send more than one and in section 2.5 we find...
The originating router MAY advertise
multiple RI LSAs as long as the flooding scopes differ.
Hope this answers the point.
Adrian
----- Original Message -----
From: "LE ROUX Jean-Louis RD-CORE-LAN"
<jeanlouis.leroux@francetelecom.com>
To: "JP Vasseur" <jvasseur@cisco.com>; "Dimitri Papadimitriou"
<dpapadimitriou@psg.com>; "Dimitri Papadimitriou"
<dimitri.papadimitriou@alcatel.be>
Cc: <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Thursday, November 17, 2005 6:47 PM
Subject: RE: IGP Extensions - CCAMP Milestones
Hi Dimitri,
Thanks for the comment.
As just explained by JP, the TE Node Cap TLV carries topology
related
parameters used as constraints in path computation. The leaking
of such
info across areas sounds useless as LSR TE visibility is limited
to one
area anyway...
But this is, of course, open to discussions. By the way, do you
have any
application in mind where such leaking would be useful?
Regards,
JL
-----Message d'origine-----
De : JP Vasseur [mailto:jvasseur@cisco.com]
Envoyé : jeudi 17 novembre 2005 16:58
À : Dimitri Papadimitriou; Dimitri Papadimitriou
Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX
Jean-Louis RD-CORE-LAN
Objet : Re: IGP Extensions - CCAMP Milestones
Hi dimitri,
On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote:
adrian,
could you explain the reasoning for having a TE specific TLV in
the
auto-mesh document with area and AS-wide flooding scope
while the TE
router cap TLV is restricted to an area flooding scope ?
shouldn't be one way or the other i.e. either restrict all TE
info
area-local or allow for TE router cap TLV with AS-wide
flooding scope
?
note: there is nothing in the TE router cap TLV that would
impact
scaling more than the TE auto-mesh TLV does
I guess that the reason for allowing both intra and inter-area
flooding scopes for automesh is obvious (we need to have TE LSP
mesh
within areas and spanning multiple areas).
So your question is probably why don't we allow the TE router
cap TLV
to be flooded across the domain ? As far as I can remember JL
already
answered this question ... JL, could you forward your email
again ?
In the meantime, I can answer it: the reason is that such TE node
capabilities are used for TE LSP computation which cannot take
into
account nodes that do not reside in the node's area.
Thanks.
JP.
thanks,
- dimitri.
Adrian Farrel wrote:
Hi,
We have two immediate milestones to address:
Oct 05 First version WG I-D for Advertising TE Node
Capabilities
in ISIS
and OSPF
Oct 05 First version WG I-D for Automatic discovery of
MPLS-TE mesh
membership
There are two personal submissions which address these topics:
draft-vasseur-ccamp-te-node-cap-01.txt
draft-vasseur-ccamp-automesh-02.txt
I propose that we move these into the WG and then kick the
tires
thoroughly.
Opinions please.
Thanks,
Adrian
.
.