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

Hi Yakov,

Thanks for your continuing input for the draft...

[further snip...]

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

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"


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

ok, agreed.  we will remove the examples here.

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

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

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

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.


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

>Yakov.