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

[Yakov Rekhter <yakov@juniper.net>]

Raymond,

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

Welcome.

> [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 yo
u
> > > 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"

I understand the reason to keep Item 3 as "MUST". But I still
think that Item 2 should be "SHOULD".
  
> >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.

Thanks.

> > > > > >    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 configurabl
e
> > > > > 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 befor
e
> > > > > 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 draf
t
> > > > > 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 i
f
> > > 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."

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

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

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.