The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE : RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
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
|
|