RE: Comment on draft-so-yong-rtgwg-cl-framework-04

Xihua,

I am fine with Curtis's reply.

Regarding the composite link in management plane, it is necessary to allow operator to configure a LSP over a composite link and select a component link that the LSP is over. I agree that, in general, the control plane is responsible to select a component link for a LSP.

Lucy

> -----Original Message-----
> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of
> Curtis Villamizar
> Sent: Wednesday, July 13, 2011 10:12 AM
> To: fu.xihua@zte.com.cn
> Cc: cvillamizar@infinera.com; andrew.g.malis@verizon.com; rtgwg@ietf.org
> Subject: Re: Comment on draft-so-yong-rtgwg-cl-framework-04
> 
> 
> In message <OF1C7973FE.0C3291A8-ON482578CC.0027EB2E-
> 482578CC.002BFEF3@zte.com.cn>
> fu.xihua@zte.com.cn writes:
> >
> >
> > Hi Authors,
> 
> One author here.  This is my personal opinion, not necessarily
> representing concensus of the set of authors.
> 
> > Firstly, I support it be a WG draft. I read through the draft and have
> > a few comments as follows:
> >
> > 1. You wrote in section 3
> >
> >    "All component links in a composite link have the same forwarding
> >    adjacency. The composite link forms one routing interface at the
> >    composite link end points for MPLS control plane. In other words,
> >    two routers connected via a composite link have forwarding
> >    adjacency and routing adjacency. Each component link only has
> >    significance to the composite link, i.e. it does not appear as a
> >    link in the control plane."
> >
> > A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link
> > created from an LSP and advertised in thesame instanceof the control
> > plane that advertises the TE links from which the LSP is
> > constructed. It could not apply to overlayer model. Pls refer to
> > rfc6107.
> 
> A link bundle as defined in RFC 4201 is a single FA.  CL is expected
> to be link link bundle with some information about groups of
> components within the bundle.
> 
> If we add TLVs to RFC 4201 then we retain backwards compatibility,
> just without the new features in older equipment.
> 
> There is no implication of an overlay model.  Also, the word "overlay"
> does not appear in rfc6107, so I am not sure why you referenced this
> RFC unless just for further general information about FA.
> 
> > In the case of heterogeneous component links, composite link could be
> > one CP instance different from component links.  I suggest you clarify
> > the CP instance between composite and component link in this section.
> 
> The paragraph in the draft that you quoted could be better worded.  We
> can take that as an action item.
> 
> > 2. You wrote in section 4
> >
> >    " a component link is configured to carry traffic under normal
> >    operation; under some situation, operator may want to configure a
> >    component link as a link for local recovery purpose, in which the
> >    composite link should not count the component link TE parameters
> >    into the composite link TE parameters for the
> >    advertisement. However, the composite link may send the traffic
> >    over the component link when a component link failure occurs."
> >
> > I am wondering if composite link don't count the recovery component
> > link and advertise summarized BW and maximum BW of this component
> > link, how can MP or CP know there is a recovery resource within
> > composite link and how much bandwidth?  Does it mean you conceal some
> > money from your wife and use it for future emergency?  :-)
> 
> That is a good analogy.  This is a tactic of very questionable value
> that is used in Ethernet Link Aggregation.  More often, all the
> component links are used for working traffic, with the amount of high
> priority traffic limited so that the loss of a component is always
> immediately recoverable for the high priority traffic.  It is also
> possible to limit BE traffic to always have an effective spare for all
> traffic.  My experience working in the core equipment vendor role is
> this capability gets requested by never used in the core.  It does get
> used in the edge as a 1:1 protection or even 1+1 where COE is used.
> 
> > 3.You mention in "Composite Link in Control Plane" as followings:
> >
> >    The route computing engine may select one group of component links
> >    for a LSP, it is necessary for signaling protocol to be able to
> >    indicate which group of component links for signaled LSP.
> 
> The above is fine as is.  Maybe we can add to it to address your
> concern but I don't think it is needed.  See below.
> 
> > I suggest you refine following description in section 6 "Composite
> > Link in Management Plane".
> >
> >    " Management Plane MUST be able to configure a LSP over a composite
> >    link and be able to selectone or a groupcomponent links for the
> >    LSP.  Management Plane MUST be able to trace which component linkor
> >    a group component links a LSP is assigned to and monitor individual
> >    component link and composite link performance."
> >
> > My concern is the action of MP and CP should be consistent.
> 
> New requirements would have to be added to the requirements document.
> At one point it was suggested that missed management requirements
> could go into a separate CL management requirements document.
> 
> In all IETF work it is assumed that anything that can be done by the
> control plane can also, at least in theory, be done in the management
> plane.  In practice, a lot of MIB implemeentations are read-only in
> major implementations, even in violation of MIBs that are defined as
> writable.  Since this is a general requirement (all protocols must
> have MIBs), it should be OK to not state it.
> 
> IMHO, doing things in the management plane is a bad idea due to much
> slower response when multiple faults occur.  For those that want to
> duplicate the characteristics of transport networks, including the
> minutes (to hours) of restoration time when multiple faults occur,
> this can be supported.  The only providers that I know of that have
> used the management plane for an IP/MPLS network have had a lot of
> trouble with it since they forego the mature LSR control plane
> software and provide functionality in a management system that may be
> home grown or commercial and not as mature or customized.
> 
> > Best Regards,
> >
> > Xihua Fu
> 
> Thank you for the comments.
> 
> Best regards,
> 
> Curtis
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg