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

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 01 Apr 2004 15:52:15 -0500

Hi Dimitri,

At 07:52 PM 3/31/2004 +0200, [email-masked] wrote:
>hi jp,
>
>see in-line:
>
>>Thanks for your useful comments here. See below,
>>At 02:18 PM 3/30/2004 +0200, [email-masked] wrote:
>>
>>>hi jl, here below several comments on this updated version of the document:
>>>
>>>1) section 5.3.1 mentions:
>>>
>>>"The solution MUST entirely preserve the concept of IGP hierarchy. In
>>>    other words, flooding of TE link information across areas MUST be
>>>    precluded."
>>>
>>>section 5.3.2 mentions:
>>>
>>>"The solution MUST also not increase IGP load which could compromise
>>>    IGP scalability. In particular, a solution satisfying those
>>>    requirements MUST not require for the IGP to carry some unreasonable
>>>    amount of extra information and MUST not unreasonably increase the
>>>    IGP flooding frequency."
>>>
>>>but section 7.12 tells:
>>>
>>>"The discovery mechanism SHOULD
>>>    be applicable across multiple IGP areas, and SHOULD not impact the
>>>    IGP scalability, provided that IGP extensions are used for such a
>>>    discovery mechanism."
>>>
>>>-> would it be possible to align these requirements, i get the 
>>>impression (please confirm) that you preclude TE link information but 
>>>you would allow for node information (auto-mesh) ? note also that the 
>>>section 7.12 doesn't tell us a lot about the expected distribution of the mesh
>>
>>The solution MUST preclude to flood TE-related link information and MUST 
>>not compromise the IGP scalability in any circumstances. That being said, 
>>IGP based mechanisms can be used for the discovery which will respect the 
>>requirement mentioned above,
>
>i understand to what you're referring, but please make it clear
>imho it would help if in section 7.12 the exact meaning of the
>following "*some* discovery mechanisms" was detailed so that the
>reader can more accurately assess the scope of the above

ok, will do

>>>2) section 7.3
>>>
>>>"   In the context of this requirement document, an optimal path is
>>>    defined as the shortest path across multiple areas taking into
>>>    account either the IGP or TE metric. "
>>>
>>>are you referring here to
>>><http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt>
>>>
>>>would you clarify ?
>>
>>Sure, we will add some text. The reason for this clarification is that 
>>there are a multitude of definitions for an optimal path: paths that 
>>minimize the max link utilization, call set up failure, ... here we just 
>>refer to the ability to compute a shortest path (using either the IGP or 
>>TE metric).
>
>ok
>
>>>3) section 7.3
>>>
>>>it is not clear for me what is behind the last part of the following 
>>>sentence
>>>
>>>"So a solution should support both mechanisms, and SHOULD allow
>>>    the operator to select by configuration, and on a per-LSP basis, the
>>>    required level of optimality. "
>>>
>>>what is meant by "level of optimality" ? is it simply "optimal - 
>>>sub-optimal" or do you have something else in mind ?
>>
>>We will clarify. The idea is that the ability to compute an end to end 
>>shortest path may not be required for all inter-area TE LSPs. Hence the 
>>solution should allow the operator to select the appropriate path 
>>computation method.
>
>ok, would be interesting to see whether operators would like to have 
>selection based on the computational method (allow for intermediate 
>computation or any other option suitable in this context) or based on the 
>optimality level (then the solution itself selects the appropriate 
>computational method) or simply both
>
>>>4) section 7.4
>>>
>>>"Another example is the requirement to set up multiple TE LSPs between
>>>    a pair of LSRs residing in different IGP areas in case a single TE
>>>    LSP satisfying the set of requirements could not be found. "
>>>
>>>why in such a case diversity would be desirable ?
>>
>>for either path protection or load balancing while minimizing the impact 
>>in case of failure.
>>
>>>got the impression that if a single path would have been feasible it 
>>>would have been selected in this case - isn't it ?
>>
>>That being said, we need to rephrase, I agree with you that this 
>>paragraph is not clear. It should read:
>>"Another example is the requirement to set up multiple TE LSPs between a 
>>pair of LSRs residing in different IGP areas. For instance, this would 
>>occur if TE LSP satisfying for instance the bandwidth requirement could 
>>be found, hence, requiring to set up multiple TE LSPs"
>
>the former point(s) seem clearer, is it "could be found" or "could not be 
>found" ?

oups ... typo, yes "could not be found"

>>>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.
>
>well i think that a contiguous LSP can still be sub-optimal hence
>i would suggest to not implicitly attach the crankback functionality
>to the signaling method, but to make clear what are the potential
>issues in terms of optimality as said "iff the path was initially
>computed as an end-to-end optimal"

not sure to see your point here ?

>>>also unclear if you refer also here to the provisioning delay ?
>>>
>>>editorially speaking it is also a bit unclear why you've splitted 
>>>section 7.7 and section 7.8 both refers to inter-area lsp recovery
>
>i don't know if this could be taken into account, this would simplify
>reading and subsequent utilisation of the document

ok

>>>6) section 7.11
>>>
>>>would it be possible to mention what's expected (or not expected) in 
>>>terms also of hard preemption ?
>>
>>ok
>
>just a hint here, is my understanding correct that the following sentence 
>"The lower priority LSP is not torn down and can continue to forward 
>traffic on a best-effort basis." infers that you would have to priority 
>high/low only so i'd would instead be more generic here in
>terms of priorities

the latter

>>>7) section 8.2
>>>
>>>what's meant by stability ? ie stability of what ? (for instance, as i 
>>>read the document, but please correct me, stability and re-optimization 
>>>are imho two features that are going in somehow opposite directions so a 
>>>trade-off has to be found here)
>>
>>We will clarify.
>
>ok
>
>>thanks for your comments !
>
>hope to see the next version soon, would also be interesting to see other 
>people commenting here

sure, thanks for your comments. Note that this draft is already the 
collection of many feed-backs from several SPs.

thanks.

JP.

>thanks,
>- dimitri.
>
>>JP.
>>
>>>thanks in advance,
>>>- dimitri.
>>>
>>>LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
>>>
>>>>Hi all,
>>>>Thanks in advance for your comments on this new revision of inter-area
>>>>TE requirements.
>>>>Regards,
>>>>JL
>>>>
>>>>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>>>>directories. This draft is a work item of the Internet Traffic 
>>>>>Engineering Working Group of the IETF.
>>>>>
>>>>>        Title           : Requirements for Inter-area MPLS Traffic
>>>>
>>>>Engineering
>>>>
>>>>>        Author(s)       : J. Le Roux, et al.
>>>>>        Filename        : draft-ietf-tewg-interarea-mpls-te-req-00.txt
>>>>>        Pages           : 20
>>>>>        Date            : 2004-3-26
>>>>>
>>>>>This document lists a detailed set of functional requirements for the
>>>>>support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) 
>>>>>which could serve as a guideline to develop the required set of 
>>>>>protocol extensions.
>>>>>
>>>>>A URL for this Internet-Draft is:
>>>>>http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r
>>>>
>>>>eq-00.txt
>>>>
>>>>>To remove yourself from the IETF Announcement list, send a message to
>>>>>ietf-announce-request with the word unsubscribe in the body of the 
>>>>>message.
>>>>>
>>>>>Internet-Drafts are also available by anonymous FTP. Login with the
>>>>>username "anonymous" and a password of your e-mail address. After 
>>>>>logging in, type "cd internet-drafts" and then
>>>>>        "get draft-ietf-tewg-interarea-mpls-te-req-00.txt".
>>>>>
>>>>>A list of Internet-Drafts directories can be found in
>>>>>http://www.ietf.org/shadow.html or 
>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>>
>>>--
>>>Papadimitriou Dimitri
>>>E-mail : [email-masked]
>>>E-mail : [email-masked]
>>>Webpage: http://psg.com/~dpapadimitriou/
>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>Phone  : +32 3 240-8491
>>>
>
>--
>Papadimitriou Dimitri
>E-mail : [email-masked]
>E-mail : [email-masked]
>Webpage: http://psg.com/~dpapadimitriou/
>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>Phone  : +32 3 240-8491
>
>

---

From: [email-masked]
Date: Fri, 02 Apr 2004 09:42:18 +0200

hi jean-louis

thanks for the clarifications; see in-line for some hints

LE ROUX Jean-Louis FTRD/DAC/LAN wrote:

> Hi Dimitri,
> 
> Thanks a lot for these comments. See additional comments on top of JP
> comments.
> 
> Cheers
> 
> JL
> 
> 
>> -----Message d'origine----- De : Jean Philippe Vasseur
>> [mailto:[email-masked]] Envoyé : mardi 30 mars 2004 14:36 À :
>> [email-masked] Cc : LE ROUX Jean-Louis
>> FTRD/DAC/LAN; [email-masked]; [email-masked] Objet : Re: TR : I-D
>>  ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
>> 
>> 
>> Hi Dimitri,
>> 
>>> "The solution MUST entirely preserve the concept of IGP
>>> hierarchy. In other words, flooding of TE link information across
>>> areas MUST be precluded."
>>> 
>>> section 5.3.2 mentions:
>>> 
>>> "The solution MUST also not increase IGP load which could
>>> compromise IGP scalability. In particular, a solution satisfying
>>> those requirements MUST not require for the IGP to carry some
>> 
>> unreasonable
>> 
>>> amount of extra information and MUST not unreasonably
>> 
>> increase the
>> 
>>> IGP flooding frequency."
>>> 
>>> but section 7.12 tells:
>>> 
>>> "The discovery mechanism SHOULD be applicable across multiple IGP
>>> areas, and SHOULD not
>> 
>> impact the
>> 
>>> -> would it be possible to align these requirements, i get the ->
>>> impression (please confirm) that you preclude TE link information
>>> but you would allow for node information (auto-mesh) ? note also
>>> that the
>> 
>> section 7.12 doesn't
>> 
>>> tell us a lot about the expected distribution of the mesh
>> 
>> The solution MUST preclude to flood TE-related link information and
>> MUST not compromise the IGP scalability in any circumstances. That
>>  being said, IGP based mechanisms can be used for the discovery
>> which will respect the requirement mentioned above,
> 
> 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)

> 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

>>> 2) section 7.3
>>> 
>>> "   In the context of this requirement document, an optimal path
>>> is defined as the shortest path across multiple areas taking into
>>> <http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metri
>> 
>> c-igp-02.t
>> 
>>> xt>
>>> 
>>> would you clarify ?
>> 
>> Sure, we will add some text. The reason for this clarification is
>> that there are a multitude of definitions for an optimal path:
>> paths that minimize the max link utilization, call set up failure,
>> ... here we just refer to the ability to compute a shortest path
>> (using either the IGP or TE metric).
>> 
>> 
>> 
>>> 3) section 7.3
>>> 
>>> it is not clear for me what is behind the last part of the
>>> following sentence
>>> 
>>> the operator to select by configuration, and on a
>> 
>> per-LSP basis, the
>> 
>> We will clarify. The idea is that the ability to compute an end to
>> end shortest path may not be required for all inter-area TE LSPs. 
>> Hence the solution should allow the operator to select the
>> appropriate path computation method.
> 
> 
> I see your point here. Basically there are two possible approaches
> for LSP configuation -Option 1: Configure only the desired level of
> optimality: Optimal, sub-optimal, then the head-end choose the
> corresponding path computation approach. -Option 2: Configure
> directly the desired path computation method: e.g. ERO expansion or
> PCE computation
> 
> Option 1 is IMHO too generic, and a Service Provider wants to have
> direct control on the selection of the path computation method.
> 
> We will clarify that in next revision

ok

>>> 4) section 7.4
>>> 
>>> "Another example is the requirement to set up multiple TE
>> 
>> LSPs between
>> 
>>> a pair of LSRs residing in different IGP areas in case a
>> 
>> single TE
>> 
>> for either path protection or load balancing while minimizing the
>> impact in case of failure.
>> 
>> 
>>> got the impression that if a single path would have been feasible
>>> it would have been selected in this case - isn't it ?
>> 
>> "Another example is the requirement to set up multiple TE LSPs
>> between a pair of LSRs residing in different IGP areas. For
>> instance, this would occur if TE LSP satisfying for instance the
>> bandwidth requirement could be found, hence, requiring to set up
>> multiple TE LSPs"
>> 
>> 
>>> 5) section 7.7
>>> 
>>> 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.
>> 
>> 
> 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

> Yes you are right, both sections refer to lsp recovery Basically
> section 7.7 deals with LSP rerouting and section 7.8 is dedicated to
> Fast Reroute protection We will update as follows 7.7 LSP recovery 
> 7.7.1 LSP rerouting 7.7.2 Fast Reroute

ok

>>> 6) section 7.11
>>> 
>>> would it be possible to mention what's expected (or not expected)
>>> in terms also of hard preemption ?
>> 
>> ok
> 
> 
>> 
>>> 7) section 8.2
>>> 
>>> what's meant by stability ? ie stability of what ? (for
>> 
>> instance, as i
>> 
>>> read the document, but please correct me, stability and
>> 
>> re-optimization
>> 
>>> are imho two features that are going in somehow opposite
>> 
>> directions so a
>> 
>>> thanks in advance, - dimitri.
>>> 
>>>> Hi all, Thanks in advance for your comments on this new
>>>> revision of
>> 
>> inter-area
>> 
>>>> TE requirements. Regards, JL
>>>> 
>>>> 
>>>>> A New Internet-Draft is available from the on-line
>>>>> Internet-Drafts directories. This draft is a work item of the
>>>>> Internet Traffic Engineering Working Group of the IETF.
>>>>> 
>>>>> Author(s)       : J. Le Roux, et al. Filename        :
>> 
>> draft-ietf-tewg-interarea-mpls-te-req-00.txt
>> 
>>>>> Pages           : 20 Date            : 2004-3-26
>>>>> 
>>>>> This document lists a detailed set of functional
>> 
>> requirements for the
>> 
>>>>> support of inter-area MPLS Traffic Engineering (inter-area
>> 
>> MPLS TE)
>> 
>>>>> which could serve as a guideline to develop the required set
>>>>> of protocol extensions.
>>>>> 
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-tewg-interar
> 
> ea-mpls-te
> 
>>>> -r
>>> 
>>> eq-00.txt
>>> 
>>> 
>>>> To remove yourself from the IETF Announcement list, send a
>>>> message to ietf-announce-request with the word unsubscribe in
>>>> the body of the message.
>>>> 
>>>> Internet-Drafts are also available by anonymous FTP. Login with
>>>> the username "anonymous" and a password of your e-mail address.
>>>> After logging in, type "cd internet-drafts" and then "get
>>>> draft-ietf-tewg-interarea-mpls-te-req-00.txt".
>>>> 
>> -- Papadimitriou Dimitri E-mail : [email-masked] 
>> E-mail : [email-masked] Webpage:
>> http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018
>> Antwerpen, Belgium Phone  : +32 3 240-8491
>> 
>> 
> 
>