Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi Adrian,

At 06:43 PM 6/11/2004 +0100, Adrian Farrel wrote:
>Hi,
>
> >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> >>would seem it should be enough for the head-end to signal the
> >>function/service it wants and not the underlying method used
> >>by nodes further in path to provide that service. If, as you
> >>mention, this is a requirement expressed by many SPs, it would
> >>be good to understand why it is so, and for the document to
> >>explain a bit about it.
> >
> >Actually I don't really understand the objection on that point.
> >The requirement seems clear for me. If there are several methods
> >supported in my network, I want to select the method on a per
> >LSP basis in order to have entire control on how the LSP is
> >signaled. This will ease LSP management.
>
>But WHY do you want to control the method?
>
>Is it because you believe one of the methods is (may be) sub-functional? 
>If that is the
>case, why do we standardise it?
>
>Is it because the methods have different applicability? That is, the 
>methods are suitable
>to different functional service requests? If so, why don't you specify the 
>service request
>and leave the network to provide the service.

well, you may want different method for different LSPs ! Thus the 
requirement for signalling the required method.

Cheers,

JP.


> > Basically there won't be hundreds of methods but just two or three
> > (contiguous, stiching, nesting..).
>
>Yes. Hopefully :-)
>
> > So it seems quite relevant to have the ability to signal the desired 
> method.
>
>It would really help  to give an example where not being able to control 
>the method would
>break the ability to provide the requested service.
>(Hint: I think I found one while looking at inter-domain protection paths. 
>But that is a
>fairly extreme situation.)
>
>I have serious concerns that allowing this approach means that we risk 
>inter-operability
>disconnects.
>
> > Let's have a look at the FRR draft: There are two modes defined, and the
> > desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> > the FRR object). I did not see any objection on that.
>
>I don't think holding the FRR draft up as a shining example is 
>particularly wise.
>
>Given that two solutions were included in the document (because the 
>authors/WG could not
>agree on a single solution?) and given that those solutions impacted the 
>service provided
>to the service requester it was necessary to allow the requester to 
>control the solution.
>In this case, controling the solution is equivalent to controling the service.
>
>Note that this feature raises interoperability questions for FRR-enabled 
>networks.
>
>If, as I say, you are able to demonstrate that the inter-domain solutions 
>impact the
>service, then you may be on to something.
>
> >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> >>underscore Adrian's point on specifying the scaling
> >>requirements themselves (with respect to areas, amount of
> >>flooded info. etc.) rather than the realization of those
> >>requirements (by not adding any info. to the LSAs, for example).
> >
> >It seems that you are OK with 5.3 (no comments)
> >"Containment of routing information MUST not be compromised to allow 
> inter-area traffic
> >   engineering. Information propagation for path-selection MUST continue
> >   to be localized.".
> >Thus you should also be OK with 7.4
>
>Or conversely? :-)
>
> > Basically we want to preserve IGP hierachy concept, are there
> > objections to that point ?
>
>None has been vocalised.
>
> > This means, for ISPs contributing to this draft, "no leaking of any
> > topology related info accross areas".
> > Of course, this does not preclude the addition of info to the LSA,
> > provided that it is not topology related.
>
>So, for example, you would not be opposed to an LSA that described 
>"aggregated TE
>reachability information"?
>
>Enjoy,
>Adrian