Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt

[JP Vasseur <[e-mail]>]

Begin forwarded message:

> From: JP Vasseur <[e-mail]>
> Date: September 20, 2006 12:06:03 PM EDT
> To: [e-mail]
> Cc: Loa Andersson <[e-mail]>, Adrian Farrel <[e-mail]>,  
> [e-mail]
> Subject: Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te- 
> lsps-02.txt
>
> resending
>
> Begin forwarded message:
>
>> From: JP Vasseur <[e-mail]>
>> Date: September 20, 2006 10:14:11 AM EDT
>> To: [e-mail]
>> Cc: "Loa Andersson" <[e-mail]>, <[e-mail]>, Adrian Farrel  
>> <[e-mail]>
>> Subject: Re: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te- 
>> lsps-02.txt
>>
>> Hi dimitri,
>>
>> On Sep 8, 2006, at 6:07 AM, [e-mail] wrote:
>>
>>> all - a couple of comments on this document
>>>
>>> o) status intended for info or std track ?
>>>
>>
>> Standard Track.
>>
>>> o) end of section 1 - what about LSPs not instantiated via  
>>> signaling ? are
>>> they also incorporated in the LSP counter ?
>>>
>>
>> Referring to TE LSP signalled.
>>
>>> o) section 2 - "Unconstrained TE LSP" why only bandwidth enters  
>>> in the
>>> definition of "unconstrained" or does it become now an new equation
>>> constraint = bandwidth ?
>>
>> This has been clarified in the text: "TE Label Switched Paths  
>> (LSPs) signalled with zero bandwdith (referred to as unconstrained  
>> TE LSP in this document)"
>>
>>>
>>> o) as the document states "There are various circumstances (detailed
>>> below) where it would be useful to also advertise the number of
>>> unconstrained Traffic Engineering Label Switch Path(s) (TE LSP)."
>>>
>>> what is the use of the other TLVs describing unreserved/reservable
>>> bandwidth in these conditions ? what about overprovisioning (wrt  
>>> #LSPs) ?
>>>
>>
>> When you signal a TE LSP with zero bandwidth then the TLVs used to  
>> advertise the reserved bandwidth are obviously unchanged.
>>
>>> o) as the document involves a procedure "An implementation may  
>>> decide to
>>> implement a dual-thresholds mechanism to govern the origination  
>>> of updated
>>> OSPF LSA or ISIS LSP."
>>>
>>> - threshold on which basis ? -
>>>
>>
>> I clarified the text:
>>
>> An implementation MAY decide to implement a dual-thresholds  
>> mechanism based on the number of unconstrained TE LSPs to govern  
>> the origination of updated OSPF LSA or ISIS LSP. Similarly to  
>> other MPLS Traffic Engineering link characteristics, LSA/LSP  
>> origination trigger mechanisms are outside of the scope of this  
>> document.
>>
>>> o) more fundamental - bandwidth gives an implicit limitation on  
>>> the number
>>> of signaling states an interface could receive - the mechanism  
>>> disappears
>>> here, counting is started from 0 if my reading is correct (the  
>>> draft does
>>> not even clearly mention how counting is performed and translated  
>>> into the
>>> field assigned in the newly defined TLV)
>>> what is the AC mechanism provided such as to prevent crashing the
>>> signaling engine since there is no limit about the number of LSPs  
>>> that can
>>> cross a given node ? in brief, there is an impact on signaling  
>>> with this
>>> draft -
>>
>> Ah NO.
>>
>> Is there anything that prevents you today to signal a TE LSP with  
>> bandwidth=0 as per RFC2205/3209? No ... so if the issue exists it  
>> has nothing to do with this draft. Note that this is a common  
>> practice in deployed networks and other IDs deal with potential  
>> out-of-resource issues from a control plane perspective.
>>
>> Thanks.
>>
>> JP.
>>
>>>
>>> thanks,
>>> - dimitri
>>>
>>>
>>>
>>>
>>>
>>> "Adrian Farrel" <[e-mail]>
>>> 05/09/2006 00:00
>>> Please respond to Adrian Farrel
>>>
>>>         To:
>>>         cc:
>>>         Subject:        Re: [mpls] WG Last Call on
>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt
>>>
>>>
>>> Hi,
>>>
>>> A quick review of this I-D leaves me puzzled by the motivation. I  
>>> don't
>>> think it is enough to say "I want to know how many unconstrained  
>>> TE LSPs
>>> traverse every link in the network"; we must have an idea of how  
>>> that
>>> information will be used.
>>>
>>> Now the I-D says:
>>>
>>> ... in the Abstract
>>>    There are various
>>>    circumstances (for example in order to load balance  
>>> unconstrained TE
>>>    Label Switched Path (LSP) across a set of equal cost paths)  
>>> where it
>>>    would be useful to also advertise the number of unconstrained  
>>> Traffic
>>>    Engineering Label Switched Path(s) (TE LSP) signalled across a  
>>> link.
>>>
>>> ... and in the Introduction
>>>    If the
>>>    number of unconstrained TE LSPs traversing each link in the  
>>> network
>>>    is known, various algorithms can be designed so as to efficiently
>>>    load balance the traffic carried onto such unconstrained TE LSPs.
>>>
>>> ...but this seems to me to be an supported assertion. I guess you  
>>> could
>>> cite
>>> a reference so you don't need to prove the algorithms here. But  
>>> it seems
>>> to
>>> me that the count of such LSPs is a very poor measure indeed. The  
>>> only way
>>>
>>> you could use it would be if you could make some fairly tight  
>>> statistical
>>> assumptions about the traffic on each LSP, or at least the  
>>> statistically
>>> aggregate traffic on a number of LSPs.
>>>
>>> Surely it would be better for the LSRs to report link usage  
>>> rather than
>>> the
>>> number of LSPs? If you are trying to protect the LFIB from excessive
>>> growth
>>> then your proposal would be reasonable, but the problem you have  
>>> stated is
>>>
>>> one of load balancing and for that you need to know the load, not  
>>> the
>>> number
>>> of LSPs.
>>>
>>> I also have the following nits and small issues in the I-D.
>>>
>>>    A Link-Type sub-TLV to convey the number of Traffic  
>>> Engineering Label
>>>                   Switch Paths signalled across a link
>>>
>>> ## Is this title right? I think your proposal is only to count  
>>> LSPs that
>>> have zero reserved bandwidth.
>>>
>>> Abstract
>>>
>>> ## I think "ISIS" should be spelled "IS-IS"
>>> ## Some acronyms need to be expanded on their first usage:
>>> ## IS-IS, MPLS, TE
>>>
>>> 1.  Introduction
>>>
>>> ## I think "ISIS" should be spelled "IS-IS"
>>> ## Acronyms have to be spelled out again (separate from the  
>>> Abstract) the
>>> ## first time they are used. Maybe move the terminology section  
>>> above the
>>> ## Introduction?
>>>
>>>    A set of Link-type sub-TLVs have been defined for OSPF and  
>>> ISIS (see
>>>    [I-D.ietf-isis-te-bis] and [RFC3630]) in the context of MPLS  
>>> Traffic
>>> ## References are in the wrong order
>>>
>>>    It is not uncommon to deploy MPLS Traffic Engineering for the  
>>> sake of
>>>    fast recovery relying on a local protection recovery mechanism  
>>> such
>>>    as MPLS TE Fast Reroute (see [RFC4090]).  In this case, a  
>>> deployment
>>>    model consists of deploying a full mesh of unconstrained TE LSPs
>>>    between a set of LSRs and protect these TE LSPs with pre- 
>>> established
>>> ## s/protct/protecting/
>>> ## Better to reorder..
>>> ## ...and protecting these TE LSPs against link..... with
>>> pre-established...
>>>    backup tunnels against link, SRLG and/or node failures.  The  
>>> traffic
>>>    routed onto such unconstrained TE LSP simply follows the IGP  
>>> shortest
>>>    path but is protected with MPLS TE Fast Reroute.
>>> ## I guess you are implying that each TE LSP is installed as a  
>>> virtual
>>> link
>>> ## in the IGP and is assigned a cost. But you haven't said so.
>>>
>>>    With MPLS Traffic Engineering a usual rerouting criteria is the
>>>    discovery of a better path for a TE LSP where a better path is
>>>    defined as a path with a lower cost according to a specific  
>>> metric;
>>>    other metric such that the percentage of reserved bandwidth or  
>>> the
>>>    number of hops can also be used.
>>> ## I can guess the meaning here, but I can't parse the sentence.
>>>
>>>    Unfortunately, for instance in the
>>>    presence of ECMPs (Equal Cost Multi-Paths) in symmetrical  
>>> networks
>>>    when unconstrained TE LSP are used, such metrics are usually
>>> ## s/LSP/LSPs/
>>>
>>>    This document specifies a new Link-type Traffic
>>>    Engineering sub-TLV used to indicate the number of  
>>> unconstrained TE
>>>    LSP signalled across a link.
>>> ## s/LSP/LSPs/
>>>
>>>    Note that the specification of load balancing algorithms is  
>>> outside
>>>    of the scope of this document and merely listed for the sake of
>>>    illustration of the motivation for gathering such information.
>>> ## Very good, but if such algorithms cannot exist based on the  
>>> data you
>>> ## are collecting, then you would do better to list another  
>>> illustrative
>>> ## example.
>>>
>>>    Furthermore, the knowledge of the number of unconstrained TE LSPs
>>>    signalled across each link can be used for other purposes (e.g.
>>>    management, ...).
>>> ## Either make some good suggestions or delete this paragraph. But
>>> ## that would be to note that the only use you have to suggest is
>>> ## "load balancing"
>>>
>>> 2.  Terminology
>>>
>>>    Unconstrained TE LSP: A TE LSP signalled with a bandwidth  
>>> equal to 0.
>>> ## When you say "a bandwidth equal to 0" you do not mean that  
>>> there is
>>> ## no traffic carried. Can you be more specific in this  
>>> definition about
>>> ## what you do mean.
>>>
>>> 3.1.  IS-IS
>>>
>>>    The NB-0-BW-LSP sub-TLV is OPTIONAL and MUST appear at most once
>>>    within the extended IS reachability TLV (type 22) specified in
>>>    [I-D.ietf-isis-te-bis].
>>> ## What should a receiver do if a second instance is encountered?
>>>
>>>    Value (4 octets): number of unconstrained TE LSP(s) signalled  
>>> across
>>>    the link.
>>> ## Do you intend to only count the TE LSPs that have been  
>>> signaled or
>>> ## are you also interested in those that have been manually  
>>> configured?
>>>
>>> 3.2.  OSPF
>>>
>>>    The NB-0-BW-LSP sub-TLV is OPTIONAL and MUST appear at most once
>>>    within the Link TLV (Type 2) that is itself carried within the
>>>    Traffic Engineering LSA specified in [RFC3630].
>>> ## As above
>>>
>>>    Value (4 octets): number of unconstrained TE LSP(s) signalled  
>>> across
>>>    the link.
>>> ## As above
>>>
>>> 4.  Elements of procedure
>>>
>>>    An implementation may decide to implement a dual-thresholds  
>>> mechanism
>>>    to govern the origination of updated OSPF LSA or ISIS LSP.   
>>> Similarly
>>>    to other MPLS Traffic Engineering link characteristics, LSA/LSP
>>>    origination trigger mechanisms are outside of the scope of this
>>>    document.
>>> ## Is that "may" actually a "MAY"? Wouldn't a SHOULD or MUST be  
>>> better?
>>> ## If the unconstrained TE LSPs are stable (i.e. not changing  
>>> often) then
>>> ## there is clearly no need for this extension as part of the  
>>> routing
>>> ## protocol - it could be safely gathered using the management  
>>> plane. So
>>> ## we must assume that the rate of change of unconstrained TE  
>>> LSPs is
>>> ## non-trivial in which case this I-D must concern itself with  
>>> the impact
>>> ## on the stability of the IGP of distributing this information.
>>>
>>> 5.  IANA Considerations
>>>
>>> ## Can you point IANA at the appropriate registries, please.
>>>
>>> 6.  Security Considerations
>>>
>>>    This document raises no new security issues for IS-IS and OSPF.
>>> ## You are distributing additional information about the network, so
>>> ## there must be an additional security consideration.
>>> ## What would happen if an LSR accientally or deliberately  
>>> misreported
>>> ## the number of LSPs? What wuld happen if that information was  
>>> spoofed
>>> ## or interfered with?
>>>
>>> 8.1.  Normative References
>>>
>>>    [I-D.ietf-isis-te-bis]
>>>               Li, T. and H. Smit, "IS-IS extensions for Traffic
>>>               Engineering", draft-ietf-isis-te-bis-00 (work in
>>>               progress), September 2005.
>>> ## Is this date right? I see August 2005.
>>> ## Anyway, the I-D has expired which is not a good sign for a  
>>> normative
>>> reference.
>>>
>>>
>>>
>>> Cheers,
>>> Adrian
>>>
>>>
>>> ----- Original Message -----
>>> From: "Loa Andersson" <[e-mail]>
>>> To: <[e-mail]>
>>> Sent: Friday, September 01, 2006 9:08 AM
>>> Subject: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te- 
>>> lsps-02.txt
>>>
>>>
>>>> Working Group,
>>>>
>>>> this initiates a two week working group last call on
>>>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt
>>>>
>>>> The wg last call ends on September 17.
>>>>
>>>> Please send comments to the working group mailing list and/or
>>>> the working group chairs.
>>>>
>>>> /Loa and George
>>>>
>>>> -- 
>>>> Loa Andersson
>>>>
>>>> Principal Networking Architect
>>>> Acreo AB                           phone:  [phone]
>>>> Isafjordsgatan 22                  mobile: [phone]
>>>> Kista, Sweden                      email:  [e-mail]
>>>>                                           [e-mail]
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/mpls
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/mpls
>>
>

_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls