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

["Maciek Konstantynowicz (mkonstan)" <[e-mail]>]

Curtis, All,

Please ignore the text I mis-quoted from Bruno below. I should not have done it - I apologise.

The actual response to this point is:

	IPR #686 is applicable to RFC5283, and not to this draft.
	To our knowledge there is no other IPR related to this draft, apart from the ones that have been already disclosed.

I replaced the original text accordingly. Hope this does address all concerned.

/maciek

On 13 Jan 2014, at 20:28, Maciek Konstantynowicz <[e-mail]> wrote:

> Curtis,
> 
> Pls see our comments inline, and let us know your thoughts.
> We have also posted updated ID.
> 
> On 15 Oct 2013, at 18:09, Curtis Villamizar wrote:
> 
>> 
>> 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.
> 
> Update from Bruno in addition to the email he sent on
> Date: 16 October 2013 08:43:46 GMT+01:00
> 
> 

	IPR #686 is applicable to RFC5283, and not to this draft.
	To our knowledge there is no other IPR related to this draft, apart from the ones that have been already disclosed.

> 
>> 
>> 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.
> 
> The use cases, proposed design and protocol choices have been driven by
> the actual SP deployments.
> 
> Design based on the hierarchy of RSVP-TE LSPs may address the listed use
> cases. However the labeled BGP design with LDP DoD has been chosen due
> to the higher degree of out-of-the-box automation and operational
> simplicity as well as compatibility with the existing backbone and
> backhaul designs & deployments which use LDP and not RSVP-TE.
> 
> It also assumes relatively simple MPLS implementations on access nodes -
> RFC 7032 goes into much more detail there.
> 
>> 
>> 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.
> 
> The requirement was to cater for service connectivity over transport
> LSPs per scaling numbers provided for listed deployment use cases. The
> required design was not to restrict the LSP based connectivity between
> the access, aggregation and backbone nodes, catering equally well for
> sparse and dense connectivity, but not the full-mesh. Full-mesh
> connectivity between between all ANs will require each AN maintaining
> LSP that they initiate and terminate, complicating the AN
> implementation. 
> Luckily this is not the case in the listed use cases and the actual
> access deployments.
> 
> 
> The result is the seamless MPLS design specified in this draft. And it
> does work for dense transport LSP connectivity between the access nodes
> without exhausting the MPLS 20-bit label space on any of the nodes by
> relying on LSP hierarchy provided by labeled BGP for inter-domain
> connectivity.
> 
> See section 5.2 for scalability analysis, and numerical examples for
> access node connectivity in section 5.2.1.5.
> 
>> 
>> 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.
> 
> We read your comment "without some form of aggregation" as meaning
> "without some form of hierarchy".
> If so, indeed this is why specified design used LSP hierarchy per
> earlier comment.
> 
>> 
>> Some indication of how dense or sparse the connectivity would be
>> useful in this section (2.1.  Why Seamless MPLS).  
> 
> Indicative access node level connectivity has been described in section
> 5.2 Scalability Analysis, but we agree that it makes sense to give an
> indication in section 2.1
> 
> Following text added in section 2.1:
> 
> Multiple Service Providers plan to deploy networks with 10k to 100k MPLS
> nodes, with varying levels of MPLS LSP connectivity between those nodes
> - sparse-mesh in access, partial-mesh in aggregation and full-mesh in
> core. This is typically at least one order of magnitude higher than
> typical deployments and may require a new architecture.
> 
>> It may be worth
>> creating a new subsection (2.2 Scaling Goals) and going into a little
>> more detail.
> 
> We believe this comment is addressed by above addition in section 2.1
> and section 5.2. Scalability Analysis. Let us know if this does address
> your comment.
> 
>> 
>> Then there is the question as to whether this draft should even go
>> forward at all.
> 
> Can you pls be more specific why you don't see this draft proceeding ?
> 
> There are production implementation by both vendors and providers of
> Seamless MPLS design as specified in this draft.
> 
>> 
>> 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.
> 
> We do not disagree that alternative design approach based on RFC 4206
> and related h-LSP RFCs may be applied to address the LSP connectivity in
> this environment.
> 
> However we believe the design specified in the Seamless MPLS draft
> better meets described requirements including better deployment
> flexibility, better scaling and easier troubleshooting.
> 
>> 
>> 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.
> 
> The draft does not propose aggregating LDP LSPs. In fact the design
> enables the operator to choose the transport LSP signalling protocol,
> LDP or RSVP-TE, per domain, per section 4.4. Intra-Domain Routing.
> 
>> 
>> 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).
> 
> In line with your comments the scaling limits are imposed not only by
> MPLS 20-bit label space, but also by the number of supported LFIB
> entries on specific MPLS node.
> 
> Design in this draft relies on labeled BGP control plane to scale the
> MPLS label distribution and to optimize the MPLS data plane on ABR nodes
> by installing only the local labelled routes in its LFIB, as described
> in section 5.1.7.
> 
>> 
>> 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.
> 
> Similarly, the scale of the design in this draft is restricted by the
> scale of AN at the outskirts of the MPLS network and their connectivity
> needs driving the scale of neighbouring AGNs.
> 
>> 
>> 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.
> 
> In the draft, labeled BGP is used for labeled routes, providing excellent
> scaling properties in the control plane.
> 
>> 
>> 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 opinion of the authors of this draft and WG members supporting
> this draft that the design described in the draft is more optimal for
> scaling MPLS into large access and aggregation deployments compared to
> RSVP-TE with hierarchical LSPs. The draft also efficiently accommodates
> capabilities of access device and the operational aspects.
> 
>> It is also not encumbered by IPR AFAIK.
> 
> IPRs are provided on non-discriminatory terms, per IETF standard.
> 
>> 
>> I don't think the draft provides a good solution.
> 
> Per earlier note, the design specified by this draft has been accepted
> by number of operators for production deployments.
> 
> /maciek
> 
>> 
>> 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
>