Re: RE : RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt

[Dimitri.Papadimitriou@alcatel.be]

hi jean-louis:

> > > Basically the solution must preserve IGP hierarchy, and thus must 
> > > preclude leaking of any TOPOLOGY related information accross areas, 
> > > including TE link information such as carried in ISIS Extended IS 
> > > reacheability TLV, or OSPF TE LSA Link TLV. Note that this also 
> > > precludes leaking of any summarized/aggregated TE information, such 
> > > that the advertisement of maximum unreserved bandwdith 
> >
> > between an ABR 
> >
> > > and any end-point LSR. We will clarify that in next revision.
> >
> > this would refine the above requirement (such TE link 
> > information would be precluded in any of its form)
>
>
> Yes , and such precluding is IMHO a key requirement to preserve 
> the main interests of IGP area partitionning isn't it ?
>
>
>
> > > In return we definitely not preclude leaking of NON 
> >
> > TOPOLOGY related 
> >
> > > information such as TE node capabilities, provided that IGP 
> > > scalability is not impacted.
> >
> > more than probably, it is not within this kind of document to 
> > provide a kind of classification of such information but the 
> > latter would help in detailing the "discovery" concepts (see 
> > also section 7.12) in terms of functionality that would be 
> > required here: identity, capability & associated capability
>
>
> You are right, we will try to be more precise as regards discovery, in
> the next revision.
> Not sure to well understand what you mean by associated capability ?

i could have call it auxiliary or something like this, it would be 
capabilities attached to a node but that are not part of the information 
from which path computation for the inter-area lsp is performed and not 
part of the information from which the signaling decisions for the 
inter-area lsp is performed (i.e. typically the pce would fall in this 
category that would indicate an access to such pce)

hope this clarifies,
- dimitri.

> > > > > 5) section 7.7
> > > > >
> > > > > "This may reduce the recovery delay, but with the risk of
> > > > > multiple crankbacks, and sub-optimality.  "
> > > > >
> > > > > i agree, but this is valid iff the head-end has initially 
> >
> > computed 
> >
> > > > > an end-to-end optimal path,
> > > >
> > > > more exactly this applies to contiguous LSP. For 
> >
> > sub-optimality this 
> >
> > > > applies to any kind of LSP.
> > > >
> > > >
> > > >
> > > > > also unclear if you refer also here to the provisioning delay ?
> > >
> > >
> > > Actually this section is not dedicated to crankback routing 
> >
> > as a path 
> >
> > > computation method,  it only addresses possible use of crankback in 
> > > case of network failure. Thus we refer here only to the recovery 
> > > delay. We may add a section dedicated to crankback routing 
> >
> > in the next 
> >
> > > revision
> >
> > i would agree to have a requirement document that includes a 
> > dedicated 
> > section on crankback functionality, hope the next release will clarify
>
>
> We will do it, while trying to stay, as far as possible, solution
> agnostic.
>
> Again thanks for these really helpfull comments
>
> Regards
>
> JL

--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491