[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt
Guys
Apologies for the late response.
I basically agree with Acee.
* It makes sense to define a new OSPFv3-TE LSA type to carry the
AS connectivity information. I think that this would probably provide a
better and more back compatible way to identify the new advertisements
than defining a new link type value.
* It also makes sense to use the same approach in OSPFv2 and
OSPFv3 and so a new OSPFv2 opaque type may be the way to go.
My other comments on the draft, from an OSPFv3 TE perspective, are as
follows.
* On the subject of identifying the other end of the inter-AS
link.
- The Link ID sub-TLV is not suitable as it SHOULD be ignored
on receipt by an OSPFv3 TE implementation.
- The Neighbor ID sub-TLV MUST be used instead. This sub-TLV
contains the neighbor's interface ID and the neighbor's 32-bit Router ID
(note that this is NOT the TE Router ID).
- Use of the Neighbor ID sub-TLV requires configuration at the
ASBR of the remote ASBR's interface ID and the 32-bit Router ID.
- You may want to advertise a global-scope IPv6 address for the
router at the other end of an inter-AS link in a Remote Interface IPv6
Address Sub-TLV. This would also need to be configured.
* As Acee pointed out, there is currently no OSPFv3 TE equivalent
to the Type 11 Opaque LSA, that is, there is no defined LSA for flooding
AS scope TE information.
* The wording needs to be changed for OSPFv3 TE when describing
the contents of a "proxy" advertisement for the backward direction of an
inter-AD TE link.
Regards
Alan Davey
------------------------------------
Alan Davey
Data Connection Ltd
Tel: +44 20 8366 1177
Fax: +44 20 8363 1039
Email: Alan.Davey@dataconnection.com
Web: http://www.dataconnection.com
> -----Original Message-----
> From: Acee Lindem [mailto:acee@redback.com]
> Sent: 26 September 2007 15:15
> To: Mach Chen
> Cc: OSPF List; Vishwas Manral; Alan Davey; CCAMP List
> Subject: Re: [OSPF] Fwd: Posting of
> draft-ietf-ospf-ospfv3-traffic-09.txt
>
> Hi Mach,
>
> On Sep 26, 2007, at 6:10 AM, Mach Chen wrote:
>
> > Hi Acee,
> >
> > Pls see inline
> >
> >
> > On 2007-09-25, at 21:05:49 Acee Lindem wrote:
> >
> >> Hi Mach,
> >> Thanks for reviewing.
> >>
> >> On Sep 25, 2007, at 4:24 AM, Mach Chen wrote:
> >>
> >>> Hi Acee and other authors,
> >>>
> >>>
> >>>
> >>> Some questions to ospfv3-traffic
> >>>
> >>>
> >>>
> >>> 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TE
> >>> LSA, is defined to advertise IPv6 TE information. From
> name of this
> >>> new LSA, IMHO, it is limited to be used for Intra-Area TE
> only. So,
> >>> if there are some underlying extensions to ospfv3-traffic, e.g.
> >>> Inter-AS TE, it is a little bit strange to re-use the
> Intra-Area-TE
> >>> LSA, or it has to define a new LSA. So, can we change its name to
> >>> something like "OSPFv3 TE LSA"?
> >> It would be if we had intended it to carry AS wide information.
> >> However, it was not initially intended for this. The
> initial thought
> >> was that we would do a better job for OSPFv3 and define
> separate LSA
> >> types for intra-area, inter-area, and AS external TE LSAs.
> Thoughts
> >> on this (copied ccamp as well)?
> >
> > So, the conclusion is that a new LSA(may be called Inter-AS-TE LSA)
> > has to be defined for advertising inter-AS TE information
> in support
> > of OSPFv3 TE, am I right?
> >
> >> I guess, IMHO, this discrepancy
> >> exposes the choice of a new link type for inter-AS
> connectivity as a
> >> bit of a hack.
> >>
> >
> > For OSPFv3 TE(separate LSAs are used) is YES. But as to OSPFv2 TE,
> > IMHO, there should be a new link type to identify an
> inter-AS link, or
> > we need another new LSA.
>
>
> It seems to me that if we do add the link in your draft, then
> it should be done the same in OSPFv2 and OSPFv3. Advertising
> it as a new link type is one way to advertise inter-AS
> connectivity. However, it isn't necessarily a link. This
> seems to me to be more of a semantical discrepancy than the
> name of the LSA. In section 4, I notice that at least for
> OSPFv2 the draft says the new link may be advertised in
> either a type 11 opaque LSA or type 10 opaque LSA. Given the
> maturity of RFC 3630, it almost seems to me that we should
> allocate a new LSA opaque type for this purpose.
>
> What is the status of draft-ietf-ccamp-ospf-interas-te-
> extension-01.txt? I know at the OSPF meeting there were a
> number of people who questioned whether or not it was necessary.
>
> Thanks,
> Acee
>
>
>
>
>
> >
> >>
> >>
> >>>
> >>>
> >>> 2. Section 2.
> >>>
> >>> "The format of the TLVs within the body of a router
> information LSA
> >>> is the same as the format used by the Traffic Engineering
> Extensions
> >>> to OSPF [TE]."
> >>>
> >>>
> >>>
> >>> What's "a router information LSA"? Or should it be "an
> Intra-Area-
> >>> TE LSA" ?
> >>
> >> Yes. Good catch. I'll fix this.
> >
> > Thanks.
> >
> >>
> >> Thanks,
> >> Acee
> >
> >
> > Best regards,
> > Mach Chen
> >
>
>