Subject: draft-so-yong-rtgwg-cl-framework-03 comments

From: Curtis Villamizar <[email-masked]>
Date: Tue, 05 Apr 2011 17:24:00 -0400

Here are some comments on draft-so-yong-rtgwg-cl-framework-03.

BTW- We should take this discussion to the WG list so that it is
archived.  The author list with a few people added covered most people
that had been active on the list anyway.

These are comments on "what is there".  I will have to comment later
on "what is not there".  A lot is missing that should be there if this
were to be a reasonably complete framework document.

1.  In a few places the following is specified: "If two unidirectional
    LSPs are used to construct a component link, they MUST be
    co-routed."

    LSP may be unidirectional, associated bidirectional, or corouted
    bidirectional.  There is no such thing as a "corouted
    unidirectional pair" since a make-before-break reroute, or any
    reroute is done on each LSP independently of the other.

    Maybe this could be put in one place and replaced with SHOULD
    since MUST is impossible during reroute.  A corouted bidirectional
    LSP will fail on a make-before-break reroute if one direction
    can't come up so it always remains either corouted or down.

2.  The requiement to make all CL LSP corouted is a new requiement.
    Requirments belong in draft-ietf-rtgwg-cl-requirement, so if we've
    missed some we SHOULD tell the IESG that we need to respin
    cl-requirement already.  Otherwise we should drop this from the
    framework.  No reason is given to require corouted.

3.  The framework states that "Both LDP [RFC5036] and RSVP-TE
    [RFC3209] can be used to signal a LSP over a composite link. The
    router of composite link ingress MUST place the LSP on the
    component link that meets the LSP criteria indicated in the signal
    message."

    This is a framework so we have to say *how* LDP and RSVP-TE will
    be used to signal a LSP over a composite link.  We should not
    define the protocol bits, just describe what information needs to
    be exchanged in order for this to happen.

    We can cite the existing LDP requirements in cl-requirements.  The
    framework needs to take the next step and indicate what is
    necessary to meet these requirements (DR#1, DR#2, and DR#3).

4.  In section 5, "The process MUST support locally and gracefully
   traffic movement process among component links. The protocol that
   facilitates this process between two composite link end points is
   for further study."

   Again, this is a requiement and the draft is a framework draft.  It
   is already covered in FR#12 in cl-requirements.

5.  Section 6, "Composite Link in Management Plane" contains nothing
    but new requirements.  Every sentence but one has the word MUST in
    it.

      Management Plane MUST keep tracking a composite link and its
      individual composite link status and configuration.

      Management Plane MUST be able to make any component link in a
      composite link active and de-activate in order to facilitate
      operation maintenance task.

      The routers of a composite link resides MUST perform the
      redistribution of the traffic flows on a de-activated link to
      other component links based on the traffic flow TE criteria.

      Management Plane MUST be able to configure a LSP over a
      composite link and be able to select a component link for the
      LSP.

      Management Plane MUST be able to trace which component link a
      LSP is assigned to and monitor individual component link and
      composite link performance.

      Management Plane MUST be able to ping individual component link
      within a composite link.

      Management Plane should build the proper commands to allow
      operator execute an optimization process.

    The last sentence has "should" in lower case.  It is not clear
    what this last sentence means.

Note that if we have missed a whole block of requirements, then we
should pull draft-ietf-rtgwg-cl-requirement out of IESG (if it got
that far) or out of AD review and give it another spin, adding the
requirements that were missed.

Curtis

---

From: Lucy yong <[email-masked]>
Date: Thu, 07 Apr 2011 05:48:06 +0000

Hi Curtis and All,

Thanks the review and comments. Here are my opinions. Please see inline.
 
> that had been active on the list anyway.
[LY] Agree in general. We may need to sync up among co-authors regarding the next steps. We have worked on the subject for long and really want to move on to the protocol extension work now. 
> were to be a reasonably complete framework document.

[LY] I am glad that you are one of co-authors who can fill in those missing.

>     can't come up so it always remains either corouted or down.

[LY] Good point. Maybe it is good to only allow a corouted bidirectional LSP as a component link. In my understanding, the term of corouted bidirectional LSP is only in the context of MPLS-TP. In RSVP-TE signaling, is there an indication for associated bidirectional or corouted bidirectional in PATH message? Does a LSP tunnel mean a corouted bidirectional LSP?
 
>     framework.  No reason is given to require corouted.

[LY] A bit clarify on this. Only the LSP that is used as a component link in a composite link needs to be corouted. A LSP over a composite link can be unidirectional, associated bidirectional, or co-routed bidirectional. 

[LY] I prefer not to respin the cl-requirement. But if majority of co-authors want doing that, I go with. We can state some reason in the framework draft. Basically, the links in IGP are bidirectional. Since a physical link is always corouted bidirectional, it is reasonable to keep this characteristics in a component link that is formed by a LSP.  Thus we don't have to differ a physical component link from a LSP based component link. Like to hear operator opinion on this.

>     necessary to meet these requirements (DR#1, DR#2, and DR#3).

[LY] Good point. We need to describe these ways. Could you take this action?

>    is already covered in FR#12 in cl-requirements.

[LY] Agree. We have some description before, and we were asked to remove it. People think that this is local functions and should not be standardized. However, two end point of composite link may need some sync-up function to facilitate each end local restoration process. The protocol extension may help this task. One example we give is to locally restore a corouted bidirectional LSP on the same component link.

[LY] Let's revise the text to reference the requirement draft and make some acceptable text.
 
> requirements that were missed.

[LY] Yes, we don't have management plane requirement in the requirement draft since we split the original draft into the requirement and framework. But, as usual, operator can't use it without management plane functions. It is better for us to have it somewhere. 

[LY] Again, I prefer not to respin the requirement draft if we can work around here. But if other co-author want to respin, I go with.

[LY] We can revise the text to make them not like the requirement. What operation can be done over a composite link.

[LY] Regarding the uploading issue. I uploaded CL framework v03 on Feb 22 in silence mode and it was shown on IETF draft announcement on the date of Feb. 23. I did not make an explicit announcement to the RTG group about this update. I'll do it in the future.

[LY] I am still in Europe for other business trip this week and next week and have limited time to response this thread. 

[LY] Thank you, Curtis, very much to work on this quickly.

Regards,
Lucy

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 07 Apr 2011 22:15:27 -0400

In message <[email-masked]>
Lucy yong writes:
> [LY] Agree in general. We may need to sync up among co-authors
> regarding the next steps. We have worked on the subject for long and
> really want to move on to the protocol extension work now.
>  
> [LY] Good point. Maybe it is good to only allow a corouted
> bidirectional LSP as a component link. In my understanding, the term
> of corouted bidirectional LSP is only in the context of MPLS-TP. In
> RSVP-TE signaling, is there an indication for associated bidirectional
> or corouted bidirectional in PATH message? Does a LSP tunnel mean a
> corouted bidirectional LSP?

I suggest that we indicate that unidirectional and associated
bidirectional MAY be supported and corouted bidirectional MUST be
supported.

> [LY] A bit clarify on this. Only the LSP that is used as a component
> link in a composite link needs to be corouted. A LSP over a composite
> link can be unidirectional, associated bidirectional, or co-routed
> bidirectional.

OK.  That wasn't clear to me.  I'm not sure why the component link
MUST be corouted.

> [LY] I prefer not to respin the cl-requirement. But if majority of
> co-authors want doing that, I go with. We can state some reason in the
> framework draft. Basically, the links in IGP are bidirectional. Since
> a physical link is always corouted bidirectional, it is reasonable to
> keep this characteristics in a component link that is formed by a LSP.
> Thus we don't have to differ a physical component link from a LSP
> based component link. Like to hear operator opinion on this.

While it may seem "nice" that the component link is corouted, I don't
think it is strictly necessary.  I like the MUST implement for
corouted and the MAY implement for others.  That way providers are
free to choose.

> [LY] Good point. We need to describe these ways. Could you take this

I just added this to my list of actions from IETF (where IETF is
somewhere on the list of actions for work in general).

For RTG CL I had two actions from the CL authors meeting.  One was to
produce a list of relevant RFCs and drafts.  The second was to produce
text saying why they are relevant.  The first of those two actions is
done (sent to authors only so far).  I also promised to review the
existing framework and that is this thread.  So I now have two open
action items including the one above.

Just to be sure I'm clear on this: the new action item is to document
how we could accomodate LDP.  Briefly what had been discussed in the
past was to measure LDP traffic and make use of some filtered value
based on the measurement as if it were a RSVP-TE reservation.  This
requires no change to LDP.  An alternate would be to have edges
measure and have a sum accumulated along the MP2P LDP tree, but that
would require an enhancement to LDP signaling.

If that is OK (the direct measurement, with no signaling change), I
can write that up and indicate that no TE (ie: CRLDP) will be done on
LDP traffic under the assumption that any high priority LDP traffic
runs over overprovisioned capacity and if there is any overprovision
LDP traffic it is BE.  I'll write a blurb on this if we agree this is
the overall approach (Dave, Ning, Andy, others - opinions?).

> [LY] Agree. We have some description before, and we were asked to
> remove it. People think that this is local functions and should not be
> standardized. However, two end point of composite link may need some
> sync-up function to facilitate each end local restoration process. The
> protocol extension may help this task. One example we give is to
> locally restore a corouted bidirectional LSP on the same component
> link.
>  

If we need a protocol, then "for further study" is unacceptable.  If
we don't need a protocol to accomplish this then it can be a local
function.  If it is a local function it could also be documented but
not mandated, allowing other techniques but providing a reference
technique.

> [LY] Yes, we don't have management plane requirement in the
> requirement draft since we split the original draft into the
> requirement and framework. But, as usual, operator can't use it
> without management plane functions. It is better for us to have it
> somewhere.

Maybe we could create a very small CL management requirements draft.
That would allow the existing CL requirements to proceed.

BTW - I'm not sure that management plane would want to ping anything.
Management plane might want to initiate a ping which would then occur
in the data plane.

> [LY] Again, I prefer not to respin the requirement draft if we can
> work around here. But if other co-author want to respin, I go with.

This is up to the WG.  Authors/editors don't have final say in a WG
document.  But then again if no one but authors replies, ...

> [LY] We can revise the text to make them not like the
> requirement. What operation can be done over a composite link.

I don't follow what you are suggesting here.  I don't think that a
requirement with a lower case "must" makes it OK in a framework.

> [LY] Regarding the uploading issue. I uploaded CL framework v03 on Feb
> 22 in silence mode and it was shown on IETF draft announcement on the
> date of Feb. 23. I did not make an explicit announcement to the RTG
> group about this update. I'll do it in the future.

OK.  Thanks.  I'm not sure why it was in some places (datatracker,
1id-abstracts) and not others (ftp site).  This sounds like a tools
problem.

> [LY] I am still in Europe for other business trip this week and next
> week and have limited time to response this thread.
>  

Same here.  Limited time.  Lots of things to keep me busy.

Regards,

Curtis