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

"tom.petch" <cfinss@dial.pipex.com> Thu, 20 September 2007 18:24 UTC

Message-ID: <005201c7fba7$d0c79740$0601a8c0@pc6>
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
From: "tom.petch" <cfinss@dial.pipex.com>
To: Mach Chen <mach@huawei.com>
Cc: ccamp@ops.ietf.org
References: <010901c7f139$01e65290$4f0c6f0a@china.huawei.com>
Subject: Re: [mpls] Ask for comments on "IGP extension in support of inter-AS"drafts
Date: Thu, 20 Sep 2007 18:35:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk

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" <mach@huawei.com>
To: <mpls@ietf.org>
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

Re: [mpls] Ask for comments on "IGP extension in … tom.petch
答复: [mpls] Ask for comments on "IGP extension in … Mach Chen