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

[Curtis Villamizar <[e-mail]>]

In message <[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