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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
[e-mail] writes:

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


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.

Thank you for the comments.

Curtis


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