Subject: Re: [mpls] Ask for comments on "IGP extension in support of inter-AS"drafts

From: "tom.petch" <[email-masked]>
Date: Thu, 20 Sep 2007 18:35:15 +0200

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  "

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.

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 and the reference be made
normative.  There may be other instances of this as well; has this been reviewed
by the authors of ospfv3-traffic?

Tom Petch

----- Original Message -----
From: "Mach Chen" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 07, 2007 12:22 PM
Subject: [mpls] Ask for comments on "IGP extension in support of inter-AS"drafts

> Hi MPLSers,
>
> Here are two I-Ds which describe extensions to the OSPF Traffic Engineering
> (OSPF-TE) and ISIS Traffic Engineering (ISIS-TE) mechanisms to support
> (G)MPLS Traffic Engineering for multiple Autonomous Systems (ASes),
> respectively. They define OSPF-TE and ISIS-TE extensions for the flooding of
> TE information about inter-AS TE links which can be used to perform inter-AS
> TE path computation.
>
> You could reach them by the following links:
>
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-0
1.txt
http://www.ietf.org/internet-drafts/draft-chen-ccamp-isis-interas-te-extension-0
1.txt
>
> I'd like to ask you to comment on the CCAMP list, thanks!
>
> Best regards,
>
> Mach

---

From: Mach Chen <[email-masked]>
Date: Mon, 24 Sep 2007 17:41:45 +0800

Hi Tom,
Thanks for your comments! Sorry for the delay reply.
Pls see inline.

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> tom.petch
> 发送时间: 2007年9月21日 0:35
> 收件人: Mach Chen
> 抄送: [email-masked]
> 主题: Re: [mpls] Ask for comments on "IGP extension in support of
> inter-AS"drafts
> 
Yes, it should be like this:" 3		Inter-AS point-to-point link"

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

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