John,

Thanks for the clarification. However, upon further thought,
the Router TLV is still not needed.

The src route calculation can be performed with just the
Link TLVs (of the TE LSAs). (The Link TLVs are an extended
form of the Router LSA with TE metrics).
A loopback address is not necessary for sucessful src route computation.

Hence, the Router TLV doesn't add any value in that regard.

Regards,
Senthil.

"Moy, John" wrote:

> Senthil-
>
> What I gathered from conversations at previous OSPF WG meetings
> was that the Router Address TLV was mandatory because they
> want to calculate an IP source route, using only information from
> the TE LSAs.
>
> I do think that draft-katz-yeung-ospf-traffic-04.txt would be better
> if more context for the LSAs formats was added. For example, what
> calculations are going to be run on the LSAs, what the calculations
> produce, and how the result is then used by RSVP/LDP. Only a summary
> is needed, not a full spec -- I think a page of text could do the job.
>
> John
>
> -----Original Message-----
> From: Senthil Venkatachalam [mailto:senthil.venkatachalamUSA.ALCATEL.COM]
> Sent: Monday, April 02, 2001 6:37 PM
> To: OSPFDISCUSS.MICROSOFT.COM
> Subject: Re: WG Last Call for draft-katz-yeung-ospf-traffic-04.txt
>
> Hi John,
>
> I have raised this issue before and I did not get
> a satisfactory answer for the following:
>
> Section 2.4.1 Router Address TLV specifies:
>
> "It must appear in exactly one Traffic Engineering LSA originated by a
> router."
>
> Why is this mandatory? This TLV should be optional.
> In other words, it should be "It must appear in at most one TE LSA"
>
> Regards,
> Senthil.
>
> "Moy, John" wrote:
>
> This is the Working Group Last Call for the I-D
> "Traffic Engineering Extensions to OSPF"
> <draft-katz-yeung-ospf-traffic-04.txt>. The
> draft describes the encoding of the basic TE
> metrics within OSPF Opaque-LSAs. The authors have
> indicated that it represents what has currently
> been deployed in cisco and juniper routers.
>
> The desired disposition of the I-D is a Proposed Standard RFC.
> Please submit comments on the document to
> the authors and/or ospfdiscuss.microsoft.com
> by Friday, April 27th.
>
> The abstract of the I-D reads as follows:
>
> This document describes extensions to the OSPF protocol
> to support Traffic Engineering, using opaque LSAs.
>
> Thanks,
> John
>
> --
>
> Senthil K. Venkatachalam senthil.venkatachalamadn.alcatel.com
>
> Off#:, MBox: (703) 679-6435 [Off]
>
> Alcatel USA (703) 679-6450 [Fax]
>
> __________________________________________________________________

--
Senthil K. Venkatachalam     senthil.venkatachalamadn.alcatel.com
Off#:, MBox:                 (703) 679-6435 [Off]
Alcatel USA                  (703) 679-6450 [Fax]
__________________________________________________________________

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]