Re: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls

[<[e-mail]>]

Curtis, Loa,

>From: Curtis Villamizar [mailto:[e-mail]] >Sent: Tuesday, October 15, 2013 7:09 PM
>
>
>Loa,
>
>No details are given in IPR #686 (applicable to RFC 5283) for the
>"Reasonable and Non-Discriminatory License to All Implementers with
>Possible Royalty/Fee."  At the very least, some terms should be given.

IPR #853 was intended to obsolete IPR #686.
If this is not reflected in the datatracker base, please let me know off-list, what procedure should be followed, and I'll try to have this fixed. (Alternatively or in parallel, anyone is free to directly contact the Patent Holder.)

IPR #853 licensing declaration is "No License Required for Implementers."

Thank you,
Bruno

>IPR #1920 and #2212 do provide details.
>
>An alternate to the use of a prefix based LDP LSP is to use a prefix
>based RSVP-TE LSP and carry the individual end-to-end LSP within it.
>This is not mentioned in the draft.  See below for details.
>
>Scaling numbers are given as:
>
>   Number of Aggregation Domains: 100
>   Number of Backbone Nodes: 1.000
>   Number of Aggregation Nodes: 10.000
>   Number of Access Nodes: 100.000
>
>This section should state that very sparse connectivity among the set
>of access nodes is expected.  For exampls, you would not expect each
>access node to have an LSP to every other access node.  Is so, more
>than 10 such access nodes aggregated prior to a prefix based LSP would
>exceed the limits of the MPLS 20 bit label space.
>
>On the other hand it would not be unreasonable to expect each of the
>10,000 aggregation nodes to be fully meshed or at least very densely
>meshed.  This can also create problems without some form of
>aggregation as a worst case graph cut set with 5000 nodes on each side
>would have 25,000,000 LSP.  A cutset of 2-5 nodes (typical core) could
>not support this (exceeds the 20 bit label space) without aggregation.
>
>Some indication of how dense or sparse the connectivity would be
>useful in this section (2.1.  Why Seamless MPLS).  It may be worth
>creating a new subsection (2.2 Scaling Goals) and going into a little
>more detail.
>
>Then there is the question as to whether this draft should even go
>forward at all.
>
>It is worth noting that a full mesh of 10.000 RSVP-TE LSP is feasible
>using hierarch.  Within the core of 100 nodes, PSC-4 can be used.
>Each of the 1,000 backbone nodes can create a PSC-3 LSP to each other
>backbone node (using above terminology, "edge" nodes in more common
>core-edge-access or core-edge-aggregation-access terminology).  If on
>average there are 10 backbone nodes per core node pair, then each core
>node has on the order of 10,000 ILM entries (about 20,000 if you
>consider 50 pairs of core nodes, each serving 20 nodes).  There are
>only 100 LSP from each core node facing the core side, so FRR can be
>very effectively deployed.  The same holds for a full mesh of the
>10.000 aggregation nodes.  If each of the 1,000 backbone nodes are
>deployed in pairs serving on average 20 nodes per pair, then an ILM
>siz on the order of 200,000 is needed.  The PSC-3 LSP used to reach
>the far side backbone node can be used, yielding only 1,000 LSP facing
>the core per backbone node.  Again, FRR can be used, with the protect
>path using the alternate core node of the designated pair.
>
>In this scenarion the access nodes may or may not be full meshed.  If
>they are full meshed, then they need to be able to support 100,000 DoD
>mode LSP.  If the are more sparsely meshed, they can support a lower
>number of DoD mode LSP.
>
>If RSVP-TE is used in this way, there is no need for aggregating LDP
>LSP.  The LDP LSP are aggregated into RSVP-TE LSP and further
>aggregated in PSC-3 LSP and PSC-4 LSP in tiers closer to the core.
>
>There are ultimate scaling limits to either approach, imposed by the
>20 bit label space.  If a full mesh is needed at a given tier T with N
>nodes, then the nodes in tier T-1 aggregating tier T needs an ILM size
>of N times the number of T nodes the T-1 node serves.  So for example,
>with a full mesh of 100,000 tier T nodes if each tier T-1 node could
>aggregate 8 tier T nodes without exceeding the 20 bit label space size
>(ILM=800,000 in this case), but could not aggregate 20 tier T nodes
>(ILM=2,000,000).  If using RSVP-TE in the core, the core is limited by
>the worst case cut set, but core sizes of on the order of hundreds are
>OK (but smaller is better).
>
>Using either RSVP-TE or LDP for aggregation the outermost T-max tier
>could have a million nodes or more as long as they were sufficiently
>sparsely connected.  This limit is independent of whether aggregation
>is via LDP or RSVP-TE.
>
>With RSVP-TE used for aggregation, T-LDP is used among the sparse mesh
>in the outermost T-max tier.  A T-LDP session is only needed if FEC
>information needs to be exchanged via LDP to support an underlying
>service, otherwise RSVP-TE alone could be used.  Using T-LDP the
>number of T-LDP TCP sessions could be a limiting factor for very
>highly connected tier T-max nodes.  Either TCB state or the 16 bit TCP
>port limit could be the limit depending on how much RAM the T-max node
>has.  OTOH if a tier T-max node out on the fringes is supporting on
>the order of 50K T-LDP sessions, it can use multiple IP addresses to
>get around the 16 bit TCP port number issue.
>
>LDP could be extended to avoid the need for T-LDP sessions using LDP
>distribution of labels that will make use of RSVP-TE LSP.  A DoD
>request would normally create a series of label bindings and swaps.
>If a full mesh of RSVP-TE LSP is know to exist within a prefix (ie:
>tier T), then the LSR can return a mapping of FEC,label,addr with its
>address.  This mapping can be passed back and at each hop that
>actually does have a direct path to that address the mapping can be
>installed and the RSVP-TE LSP used as an outer label, even if there is
>no T-LDP session to that address.  (btw- AFAIK no such extension
>exists, I'd be happy to be wrong about that).
>
>IMHO using RSPV-TE is a viable and IMHO better solution for the
>problem posed in this draft.  It is also not encumbered by IPR AFAIK.
>
>I don't think the draft provides a good solution.
>
>Curtis
>
>
>
>In message <[e-mail]>
>Loa Andersson writes:
>
>Working Group,
>
>I'll will keep this wglc open until October 21st, there are several
>reasons.
>
>- the subject line did not explicitly say that this was a working group
>   last call
>- we had a very late IPR disclosure, and we are still looking into that.
>   We should like to draw the attention to the expectation that IPRs
>   need to be disclosed in a timely fashion after your name appears on
>   on a document, we are talking days or weeks, rather than months; and
>   certainly not years
>- we have not seen any comments on the list, we are therefore now also
>   asking if there is support to progress the draft.
>
>/Loa
>
>
>
>On 2013-09-26 13:37, Loa Andersson wrote:
>> Working Group,
>>
>> this is to start a two week+ working group last call on
>> draft-ietf-mpls-seamless-mpls-05.
>>
>> Please send your comment to working group mailing lists ([e-mail]).
>>
>> We did an IPR poll on this document prior to starting the wglc.
>> All the authors responded to the IPR poll that they are not aware of
>> any IPR's relating to this document other than the one already
>> disclosed.
>>
>> There are no IPRs disclosed directly against this document, disclosure
>> #1920 was disclosed against an earlier individual version of the
>> document.
>>
>> It has also been pointed out that one of the components in the Seamless
>> MPLS architecture is derived from RFC 5283 and that IPR disclosures
>> # 686 and # 853 are applicable.
>>
>> The working group last call will end Friday October 11, 2913.
>>
>> /Loa
>
>--
>
>
>Loa Andersson                        email: [e-mail]
>Senior MPLS Expert                          [e-mail]
>Huawei Technologies (consultant)     phone: [phone]
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.