[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
.







.