Subject: Re: few comments on draft-ietf-tewg-interas-mpls-te-req-01.txt

From: Yakov Rekhter <[email-masked]>
Date: Mon, 01 Dec 2003 10:57:25 -0800

Raymond,

> Hi Yakov,
> Thanks for the response...
> 
> [snip...]
> 
> >Perhaps I missed it, but the -02 version still does not include
> >this "good point".
> 
> Sorry...  -02 was posted right before your email to list showed up. I'll 
> make sure this point is well reflected in the text (in section 6.1)

Ok. 

> > > >With this in mind the following in 6.1 should be removed:
> > > >
> > > >    It MUST meet all the requirements described in section 5 each
> > > >    time a MUST is specified.
> > > >
> > > >and be replaced with the following:
> > > >
> > > >    It MUST document whether it meets each requirement described
> > > >    in section 5.
> > >
> > > Well in a requirements doc, is it not the case that when there is a MUST,
> > > then the solution MUST meet the requirement ?
> >
> >Unless there is an existence proof that it is possible to have a
> >practical solution that meets all the requirements in section 5
> >that are "MUST", saying that a solution "MUST meet all the requirements
> >described in section 5 each time a MUST is specified" is nothing
> >but a wishful thinking.
> 
> There are only a few "MUST" in section 5 of -02 now:
> 1. Section 5.1.1. " ..the derived solution MUST be such that it will 
> interoperate seamlessly with current intra-AS MPLS TE mechanism..."
> 2. Section 5.1.1. "The proposed solution MUST allow to provision at the 
> Head/Tail end with end-to-end RSVP signaling (eventually with loose paths)
>     traversing across the interconnected ASBRs, without further 
> provisioning required along the transit path."
> 3. Section 5.1.5. "...the solution MUST be able to re-optimize the LSP 
> accordingly and non-disruptively, either upon expiration of a configurable 
> timer or
>     triggered by a network event or a manual request at the TE tunnel 
> Head-end."
> 4. Section 5.1.10.1 "This new MIB MUST extend (and not reinvent) the 
> existing MIBs to accommodate this new functionality."
> 
> 5. Section 5.2.2.1 "The signaling of a non policy compliant request MUST 
> trigger the generation of a RSVP Path Error message by the policy enforcing
>     node towards the Head-end LSR, indicating the cause."
> 6. Section 5.2.2.2. "the re-writing node MUST generate a RSVP Path Error 
> Message towards the Head-end LSR indicating the cause in terms
>     of types of changes made so as to maintain the end-to-end integrity of 
> inter-AS TE LSP."
> 
> In -03, we will change "MUST" to "SHOULD" for item 5 and 6 above.

That would be fine.

> As for 1, 2, 3 and 4, they constitute, in our thinking, a basic set of 
> requirements for the deployments of inter-AS TE.  It would be great if you 
> could clarify further of each of item 1, 2, 3 and 4 on any technical 
> limitations or impracticality such that these "MUST" requirement can not 
> all be met in a solution ?

I think that 2 and 3 should be "SHOULD", rather than "MUST".

> 
> > > But to the merit of your first point, maybe we can propose to add this in
> > > section 6.1 : "if a solution can fulfill just a subset of those
> > > requirements in section 5, then it MUST be explicitly documented"
> > >
> > > >2. Since this is a *requirements* document, other than relying on the
> > > >existing MPLS/DiffServ TE mechanisms, the document should not presume
> > > >a particular solution.
> > >
> > > Indeed. This point was mentioned before. As a result, references as 
> > such in
> > > the latest revision of  the document have been reworded as examples, 
> > merely
> > > to illustrate or help in understanding the corresponding requirements.
> > >
> > > >Therefore references to such specific solutions like PCS (e.g., in
> > > >section 5.1.2) should be removed from the document.
> > >
> > > Similarly, the mention of this is merely an example to illustrate the
> > > requirements in path computation...
> >
> >Sorry, but the -02 version of the document still talks "... require
> >a discovery mechanism of some PCS using IGP extensions".
> >
> >Also, may I suggest that the requirements document should focus on the
> >requirements and not on the specific examples of how to meet the
> >requirements.
> 
> Right.  To this point, I will simplify the wording of the examples in this 
> section (tho I don't want to remove the example entirely since I feel it 
> does help in further illustrating the stated requirement). How about 
> the following wording ?

This is a *requirement* document, not a document about examples of
mechanisms that meet the requirements. Therefore, I still think
that the documents should describe requirements. Other documents
that describe specific solutions would provide examples of mechanisms
that meet the requirements.

> Section 5.1.2
> "...
> For example, one may provide a manual description of all or some of the 
> hops (loose routing) the TE LSP must traverse, allowing to keep the 
> information related to the intra-AS resources confidential while still 
> leaving intra-AS routing decisions to local operators.  

Could you please explain how "manual description of all.. of the
hops the TE LSP must traverse" would result in "leaving intra-AS
routing decisions to local operators".

>                                                        Another example is 
> an automated way of setting up the TE LSP without any static configuration 
> on the Head-End LSR by ways of requesting the computation of an inter-AS TE 
> LSP to some path computation elements..."

> 
> > > >Likewise, the following in 5.1.5 has to be removed:
> > > >
> > > >    The solution SHOULD support the ability for intermediate nodes to
> > > >    signal the respective Head-End LSRs of the existence of a more
> > > >    optimal path.
> > > >
> > > >(as it presuppose a particular way of establishing an optimal path).
> > >
> > > This is actually one of our requirements that a SP with inter-AS TE HE
> > > would like to be notified if there is a more optimal path opening up 
> > over a
> > > transiting AS.  This way the HE SP can 1). LSR can have a configurable
> > > choice to optimize or not  depending upon the available capacity in its 
> > own
> > > AS should the ASBR exist point change for the re-opt path.  2). in case 
> > the
> > > more optimal path yields for example, a worse delay (over a longer path 
> > due
> > > to some mis-configured TE metrics, e.g.), the notification would provide
> > > additional clue for HE SP to determine the cause of problem
> > >
> > > Also in some cases, the Head-end LSR may want to control the 
> > reoptimization
> > > process, especially when carrying sensitive traffic (because
> > > reoptimization, although not traffic disruptive (thanks to make before
> > > break), does generate jitter and potentially packet reordering, something
> > > not desirable for some TE LSPs. In that case, the solution SHOULD 
> > provide a
> > > mode whereby intermediate nodes can signal the existence of a better path
> > > and then the head-end LSR will decide whether to perform a reoptimization
> > > or not. Note that this is a requirement from various SPs on this draft 
> > > and is listed as a SHOULD.
> >
> >Let's not confuse requirements with the mechanisms to support the
> >requirements.
> 
> Right...  I would also like to further clarify that the requirement calls 
> for the HE LSR of the inter-AS TE LSP to have control of re-optimization 
> not only for the AS segment in its own AS, but also for transit AS segments 
> as well.
> 
> 
> >The requirement here is for the Head-end LSR under control of local
> >configuration to be able to reoptimize the path, if and when a "better"
> >path becomes available.
> >
> >Requiring intermediate nodes to provide the information about
> >a more optimal path over a transit AS to the Head-end LSR is *one
> >possible mechanim* to support the requirement.
> 
> Yakov, I do see your point regarding "mechanism".  But we'd still like to 
> keep the requirement in our response above.  Can I then propose the 
> following wording to replace this paragraph ?
> 
> "The solution SHOULD provide an option for the Head-End LSRs to control if 
> re-optimizing or not should there exist a more optimal path in one of the 
> transit ASes along the inter-AS TE LSP path."

Sorry, but this is way too restrictive, as it restricts the the
more optimal path to follow the same sequence of ASs as the original
TE LSP ("a more optimal path in one of the transit ASes along the
inter-AS TE LSP path"). With this in mind, if you still want
to keep the requirement it should be:

   The solution SHOULD provide an option for the Head-End LSRs to control 
   if re-optimizing or not should there exist a more optimal path between
   the Head-End and the Tail-End LSRs.

> > > >3. In Section 5.1.3 the document needs to explicitly state whether
> > > >it is a requirement to maintain optimal path all the time, and if
> > > >not then what percentage of overall path life time.
> > >
> > > Well, for some LSPs (not all, but some LSPs) it is desirable to have a
> > > solution being able to compute an optimal end to end path (a requirement
> > > for SPs on the draft). The question of whether the TE LSPs should 
> > always be
> > > on the optimal is a question of implementation agreement and parameter
> > > setting. The requirement here is just that the solution must offer the
> > > possibility on compute an optimal path end to end (again by optimal we 
> > > mean "shortest path").  Note this is a requirement listed as a "SHOULD".
> >
> >If the requirement here is to compute an optimal path end to end
> >just for the sake of computation, then what are the practical
> >benefits of such a requirement ?
> >
> >And if the requirement here is to compute an optimal path end to
> >end for the sake of using it (means establishing an LSP along such
> >a path), then the requirement has to be very explicit with respect
> >to whether it expects path optimality to be maintained all the time
> >or not, and if not then what percentage of the time.
> 
> This requirement is indeed for the ability to establish an optimal
> path e2e for the inter-AS TE LSP ("using it").  For example, this
> ability may be required for a SP with multiple ASes to be able to
> deploy a set of meshed TE LSPs optimally across their own AS
> boundaries and once established, it should be maintained at all
> times.  However, in some cases it is also a matter of tuning,
> trade-off between optimality and network stability, ... on whether
> path optimality should be maintained  "all the time"  or triggered
> after some timer has elapsed.  At the end, what we are actually
> after in the req's draft is that a solution should offer this
> capability of computing an optimal inter-AS TE LSP path ("shortest")
> end to end.
> 
> Will have some additional wordings then to reflect what we corresponded 
> above. Your thoughts ?

Please propose "some additional wording".

> > > >4. Sections 6.2 ("Scalability and Extensibility"), 6.3 ("Complexity
> > > >and Risks"), and 6.5 ("Backward Compatibility") talk about requirements
> > > >on scalability and extensibility, and therefore should be moved
> > > >into Section 5.
> > >
> > > Will do.. Thanks.
> >
> >-02 version still doesn't reflect this.
> 
> It will be in -03, thanks.

Thanks !!!

Looing for the -03 version.

Yakov.

---

From: raymond zhang <[email-masked]>
Date: Wed, 03 Dec 2003 09:43:14 -0800

Hi Yakov,

Thanks for your continuing input for the draft...

[further snip...]

>I think that 2 and 3 should be "SHOULD", rather than "MUST".

Sorry, our thoughts differ a bit on this point.

Item 2 is a requirement, for examples (among others), some SPs with 
multi-ASes within their own administrative domain in which SP may want to 
do traffic optimization across the entire network (therefore across their 
internal AS boundaries).  Without item 2, it would make the provisioning of 
meshed TE LSPs very difficult if the SP needs to do four-point (rather than 
HE/TE only) provisioning in their own networks - may be hard to manage and 
may not scale.

Item 3  have already been implemented and deployed in existing intra-AS 
MPLS TE.  So I think this belongs to the "MUST" list of  requirements as well..

For these reasons, I still feel that both of these two items (2 and 3) 
should remain as "MUST"

>that meet the requirements.

ok, agreed.  we will remove the examples here.

>    the Head-End and the Tail-End LSRs.

Good point on the option of traversing the same path...   So we will make 
our original point as a
special case to your proposed wording above by adding the following:

"In the case of an identical set of traversed path, the solution SHOULD 
provide an option for the Head-End LSRs to control if
re-optimizing or not should there exist a more optimal path in one of the 
transit ASes along the inter-AS TE LSP path."

>Please propose "some additional wording".

Here it is...

This requirement provides the ability for TE Head-end LSR to compute and 
establish
an optimal end-to-end path for the inter-AS TE LSP.  Once established, it
may be maintained at all times.  However, in some cases it is also a matter
of tuning trade-offs between optimality and network stability that SPs may 
elect to
follow an optimal path, for example only when triggered after some timer 
has elapsed.

>Looing for the -03 version.

If your are ok with the above, I will post the -03 by the end of this week.

Thanks once again,
Raymond

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 03 Dec 2003 11:41:48 -0800

Raymond,

> Thanks for your continuing input for the draft...

Welcome.

> MPLS TE.  So I think this belongs to the "MUST" list of  requirements as well
> 

I understand the reason to keep Item 3 as "MUST". But I still
think that Item 2 should be "SHOULD".
  
> ok, agreed.  we will remove the examples here.

Thanks.

> transit ASes along the inter-AS TE LSP path."

Why do you need this "special case" ? In other words, why the text I
proposed is not enough ?

> establish an optimal end-to-end path for the inter-AS TE LSP. Once 
> established, it may be maintained at all times. However, in some cases 
> it is also a matter of tuning trade-offs between optimality and network 
> stability that SPs may elect to follow an optimal path, for example only 
> when triggered after some timer has elapsed.

How about the following:

   Even if at the LSP's setup time path computation is optimal, the
   path may not remain optimal for the life-time of the LSP. It is
   a non-requirement to maintain path optimality all the time. The
   solution SHOULD provide mechanism(s) to reduce (but not eliminate
   altogether) path suboptimality over the life-time of the LSP.

Yakov.

---

From: raymond zhang <[email-masked]>
Date: Thu, 04 Dec 2003 12:13:38 -0800

Hi Yakov,

>think that Item 2 should be "SHOULD".

Ok since there are only some SPs who have multi-ASes.  So I will change 
item 2 to "SHOULD".

>Why do you need this "special case" ? In other words, why the text I

Well, in your proposed text, it is not specified if this HE LSR/TE LSP is 
the HE/TE of the inter-AS LSP or just
a segment of the inter-AS LSP.  Our requirement is to have the HE LSR of 
the inter-AS TE LSP, not just the mid point LSR of
segment LSP to have the control if re-opt or not in the case that inter-AS 
TE LSP needs to traverse along the same AS path.
So it is much better to make things explicit this way.

> > > > > > Well, for some LSPs (not all, but some LSPs) it is desirable to 
> have
>a
> > > > > > on the optimal is a question of implementation agreement and 
> paramete
>r
> > > > > > setting. The requirement here is just that the solution must 
> offer th
>e
> > > > > > possibility on compute an optimal path end to end (again by 
> optimal w
>e
>    a non-requirement to maintain path optimality all the time.

This is basically the same as what I proposed above.

>The

I am afraid that I disagree here... "Reducing sub-optimality" is not the 
same as the explicit requirement of "achieving e2e optimality". The 
solution SHOULD provide mechanism(s) to compute and establish an optimal 
end-to-end path for the inter-AS TE LSP.

Thanks
Raymond

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 04 Dec 2003 15:52:44 -0800

Raymond,

Thanks !!! 

> TE LSP needs to traverse along the same AS path.

Are you saying that your requirement applies only when the new and the
old path traverse the same set of ASs ?

> end-to-end path for the inter-AS TE LSP.

Ok. So how about the following:

   The solution SHOULD provide mechanism(s) to compute and establish
   an optimal end-to-end path for the inter-AS TE LSP. However,
   even if at the LSP's setup time path computation is optimal, the
   path may not remain optimal for the life-time of the LSP. It is
   a non-requirement to maintain path optimality for the life-time
   of an LSP. The solution SHOULD provide mechanism(s) to reduce (but 
   not eliminate altogether) path suboptimality over the life-time 
   of the LSP.

Yakov.

---

From: raymond zhang <[email-masked]>
Date: Fri, 05 Dec 2003 12:05:48 -0800

Hi Yakov,

 > > > >    The solution SHOULD provide an option for the Head-End LSRs to 
contr
>ol
> > > > >    if re-optimizing or not should there exist a more optimal path 
> betwe
>en

Oh no,,, this is just one of the applicable cases.

> > > > > > > > >3. In Section 5.1.3 the document needs to explicitly state 
> wheth
>er
> > > > > > > > >it is a requirement to maintain optimal path all the time, 
> and i
>f
> > > > > > Will have some additional wordings then to reflect what we 
> correspond
>ed
> > > > > > above. Your thoughts ?
> > > > >

After giving some more thoughts on this, sorry but I think the text "It is 
a non-requirement to maintain path optimality for the life-time of an LSP." 
is too restrictive...   It may be a requirement to maintain path optimality 
at all times also in either inter-area or AS's case (for SPs with multi-ASs 
in their network).

How about the following with slight modification:

"The solution SHOULD provide mechanism(s) to compute and establish
an optimal end-to-end path for the inter-AS TE LSP and SHOULD also
allow for reduced suboptimality since the path may not remain optimal
for the life-time of the LSP "

This would then cover all of our concerns, yes ?

If so, I would like to post -03 to reflect what we've discussed up until 
now by this weekend so that I can get the last call process started...

Thanks once again for your input.
Raymond

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 06 Dec 2003 19:20:52 -0800

Raymond,

> control
> > between

I still don't quite understand what it adds...

> > > > > > > > > mean "shortest path").  Note this is a requirement listed as 
a
> > > > > > "SHOULD".

Ok.

Yakov.

---

From: raymond zhang <[email-masked]>
Date: Mon, 08 Dec 2003 13:45:23 -0800

Hi Yakov,

At 07:20 PM 12/6/2003 -0800, Yakov Rekhter wrote:
> > > > > > "In the case of an identical set of traversed path, the 
> solution SHOU
>LD
> > > > segment LSP to have the control if re-opt or not in the case that 
> inter-A
>S

I should probably clarify this a bit then...  Looking at the following 
diagram (example):

                                 <--------- AS2 
----------->              <------ AS3--------->
PE1 - P1 - P2 - ASBR12 <----> ASBR21- ...- ASBR23 <--------> ASBR32 - P3...-PE4
            |            |                                          | 
|
            P3 -------ASBR14 <-----> ASBR41-...- ASBR43 <---------> ASBR34 
---
<------ AS1 ------------------>          <--------- AS4 
---------->               <------ AS3------->

If the original inter-AS TE LSP is built along AS1 - (via ASBR21) AS2 - 
AS3, then my thinking is that there maybe two cases where a more optimal 
path is available to the HE LSR of the inter-AS TE LSP:

Case 1. Still follows AS1/AS2/AS3 but a more optimal path is available 
between ASBR21 and ASBR23 ( or a different ASBR from ASBR21 or ASBR23 in 
the same AS2, (not shown in the diagram though))
Case 2. A more optimal path is available along AS1/AS4/AS3  (different path 
from the original).

So in either of above cases, we would like to provide an option (SHOULD) 
for PE1 in AS1 (HE of the inter-AS TE LSP) to control if re-opt or not.

Your proposed wording would cover case 2, however I don't think it is 
adequate or explicit enough to address requirement for case 1.  So I'd like 
to have a more explicit statement which is in my proposed wording as a 2nd 
paragraph.

Regards,
Raymond