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

[[e-mail]]

Hi Curtis,

Thank you for your clarification.

One further comment.

> 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.

I am sorry make you confuse. Based on [RFC4206], the LSP is advertised as 
an FA into the same instance of the IGP
as was used to advertise the TE links that the LSP traverses. This is well 
applied to CP peer model.
RFC6107 extends LSP_TUNNEL_INTERFACE_ID to carry the IGP instance 
where  the link formed by the LSP is to be advertised. IMO, this could be 
used to overlayer model.
If one component is from OTN network and CL is in MPLS network, they 
should be in different CP instance. This is reasonable.
Current protocol (e.g., rfc6107) can provide this function.
My concern is a framrwork document should allow this happen.

Xihua

> 
> In message <OF1C7973FE.0C3291A8-ON482578CC.0027EB2E-482578CC.
> [e-mail]>
> [e-mail] 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
>