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

[Arthi Ayyangar <arthi@juniper.net>]

Hi,

IMO it should suffice to request the service instead of specifying which
signaling method to use to deliver that service. As Vishal mentioned,
different networks may use different methods to deliver the same service.
In fact, each network may have its own motivations to choose one method
over the other, for whatever reasons, and that should be fine.

I don't see how a HE equipment can grasp the various considerations and
limitations of some other network. I understand that there is need to
request a service per LSP, but I don't see how equating a type of
service to a signaling method buys us anything.

Instead, if we invest some effort into making sure that the requested
service is understood and first identify what parameters constitute this
service and put in processing rules or ways for the downstream node to map the
incoming request to a service definition, it may help.

thanks,
-arthi

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