[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
答复: [mpls] Ask for comments on "IGP extension in support of inter-AS"drafts
Hi Tom,
Thanks for your comments! Sorry for the delay reply.
Pls see inline.
> -----邮件原件-----
> 发件人: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] 代表
> tom.petch
> 发送时间: 2007年9月21日 0:35
> 收件人: Mach Chen
> 抄送: ccamp@ops.ietf.org
> 主题: Re: [mpls] Ask for comments on "IGP extension in support of
> inter-AS"drafts
>
> A minor editorial on draft-ietf-ccamp-ospf-interas-te-extension-01.txt.
>
> Since 3.2 says
> "The value of the Link Type for an inter-AS point-to-point link is 3. The
use
> of multi-access inter-AS TE links is for future study"
> I think that s6. IANA Considerations should also be specific to
point-to-point
> and not just
> " 3 Inter-AS link "
Yes, it should be like this:" 3 Inter-AS point-to-point link"
>
> And a more substantive issue. The I-D claims to be OSPF version agnostic
but,
> as draft-ietf-ospf-ospfv3-traffic-08.txt (cited as an Informative
Reference
> only) says
> "A new LS type is defined for the Intra-Area-TE LSA. This is
> different from OSPFv2 Traffic Engineering [TE] where opaque LSAs are
> used to advertise TE information [OPAQUE]."
> which leaves me thinking that that should be a normative reference and
that
> text such as
> "Type 10 opaque LSAs [RFC2370] are used to carry such TE information"
> needs stretching to encompass OSPFv3.
Yes, we will make this a Normative Reference.
Here is the suggested text for use in Section 1:
"[OSPF-TE-V3] defines similar extensions to OSPFv3 [OSPFV3], it defines a
new LSA which is referred to as Intra-Area-TE LSA, to advertise TE
information. [OSPF-TE-V3] uses "Traffic Engineering Extensions to OSPF"
[OSPF-TE] as a base for TLV definitions and defines some new TLVs and
sub-TLVs to extend TE capabilities to IPv6 networks."
>
> Likewise, 3.3. Link ID says
>
> " For an inter-AS link, the Link ID carried in the Link ID sub-TLV is
> the remote ASBR identifier which could be any address of the remote
> ASBR(e.g., the TE Router ID, Router ID or interface address of the
> remote ASBR reached through this inter-AS link). The TE Router ID is
> RECOMMENDED.
>
> whereas ospfv3-traffic says
>
> " The Link ID sub-TLV is used in OSPFv2 to identify the other end of
> the link. In OSPFv3, the Neighbor ID sub-TLV MUST be used for link
> identification. In OSPFv3, The Link ID sub-TLV SHOULD NOT be sent
> and MUST be ignored upon receipt.
>
> Again, looks like the language needs stretching
Yes,
As to the Section 3.3 "Link ID", actually, using Remote ASBR ID is more
suitable for an inter-AS TE link. If only for OSPF v2 TE, using Link ID to
carry the Remote ASBR ID is OK. But the remote ASBR identifier could be an
IPv4 address or an IPv6 address, using Link ID sub-TLV(OSPF-TE-v2) ,Neighbor
ID sub-TLV(OSPF-TE-v3) or other legacy sub-TLVs to carry the Remote ASBR ID
is not suitable. So, a new separate sub-TLV: Remote ASBR ID sub-TLV, is
needed to carry the Remote ASBR ID, just as defined in the "ISIS inter-AS TE
extension" document.
> and the reference be made normative.
Yes, as you suggested, the reference will be updated in the next revision
(version 02).
> There may be other instances of this as well; has this been reviewed
> by the authors of ospfv3-traffic?
We hope to receive more comments and suggestions from the authors of
ospfv3-traffic and others, and we will continue to notify the OSPF working
group of our progress.
>
> Tom Petch
>
Thanks again!
Best regards,
Mach Chen