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

From: [email-masked]
Date: Wed, 13 Jul 2011 16:00:31 +0800

Hi 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 the same instance of 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.
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.

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?  :-)

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

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 select one or a group component links for the LSP.
   Management Plane MUST be able to trace which component link or 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.

Best Regards,

Xihua Fu

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 13 Jul 2011 11:12:24 -0400

> 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:
>  
>    "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
> 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

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.

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

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

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.

> Xihua Fu

Thank you for the comments.

Best regards,

Curtis

---

From: Lucy yong <[email-masked]>
Date: Wed, 13 Jul 2011 18:22:39 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Curtis Villamizar
> Sent: Wednesday, July 13, 2011 10:12 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Comment on draft-so-yong-rtgwg-cl-framework-04
> 
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: [email-masked]
Date: Thu, 14 Jul 2011 15:20:12 +0800

Hi Curtis,

Thank you for your clarification.

One further comment.

> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jul 2011 10:01:09 -0400

In message <[email-masked]>
[email-masked] writes:

This is a multipart message in MIME format.
--=_alternative 00284D93482578CD_=
Content-Type: text/plain; charset="US-ASCII"
> 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

Xihua,

A multi-layer multi-topology (ML/MT) deployment is not an overlay.  In
an overlay the underlying layer does not participate in the client
layer routing.  In ML/MT (or MLN/MLR), the underlying layer acts as a
peer in the client routing and signaling but partitions each client
into a separate logical topology and keeps a separate topology for the
server layer.  This is very different from an overlay.

A FA advertisement exists within an IGP instance.  There may be more
than one IGP instance as per OSPF ML/MT extensions [RFC4915] or ISIS
ML/MT extensions [RFC5120].  This is extended to GMPLS with RFC5212,
RFC5339 and RFC6001 (where it is called MLN/MRN).  RFC6107 continues
to support the notion of an IGP instance.  The purpose of all of this
work is to avoid the lack of sufficient functionality that results
from building an overlay but also avoid the mixing of multiple client
topologies and a server topology that would occur in a pure peer
network.

As I said earlier, the paragraph that you quoted could stand to be
more clear and we will take rewording as an action item.  This
document needs a bit of general rewording for clarity, and we'll make
a point of rewording this paragraph since you have pointed out a lack
of clarity.

This text was written by Ning or Lucy, but I also have a habit of
referring to the FA advertisement and just writing "the FA" when
writing about the IGP.  It is too easy for a reader to lose context
(discussion of the IGP) and read "the FA" to mean the LSP and not the
advertisement of the LSP in the IGP.  Going through the text and
finding references to "FA" that don't specify the LSP or the IGP
advertisement is simple enough and might improve clarity.

Curtis