Transcript Extensions to OSPF-TE for Inter-AS TE draft-ietf-ccamp-ospf-interas-te-extension-01.txt Mach Chen()

Extensions to OSPF-TE for
Inter-AS TE
draft-ietf-ccamp-ospf-interas-te-extension-01.txt
Mach Chen([email protected])
Renhai Zhang([email protected])
IETF 69#, CCAMP WG Chicago 07/24/2007
Changes since Prague
meeting(ietf 68th)
 Adopted as a WG document
 A new section , Section 2.1: “A Note on Non-Objectives”, is added to
clarify some concerns about this I-D.
Make a clearly statement about “Not to do” in this document
 A new section (Section 7), Acknowledgments, is added to thank
Adrian, Acee, JP, and Dean Cheng for their review and comments.
 Update references and add some new essential references (
according to the comments from Acee)
 Some wording and formats changes to fix some nits
IETF 69#, CCAMP WG Chicago 07/24/2007
Changes since Prague
meeting(cont.)
 Address a technical point from Jean-Louis Le Roux about Link ID
sub-TLV (should not be limited to TE Router ID)
Re-write the description about Link ID sub-TLV:
From:
“For an inter-AS link, the Link ID carried in the Link ID sub-TLV is the TE
Router ID of the remote ASBR reached through this inter-AS link.”
TO:
“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 (i.e. the TE
Router ID, Router ID or interface address of the remote ASBR) reached
through this inter-AS link. Normally, the TE Router ID is recommended.”
IETF 69#, CCAMP WG Chicago 07/24/2007
Next step
 Solicit inputs from OSPF WG
 This I-D is very small and now stable.
IETF 69#, CCAMP WG Chicago 07/24/2007
Extensions to ISIS-TE for
Inter-AS TE
draft-chen-ccamp-isis-interas-te-extension-01.txt
Mach Chen([email protected])
Renhai Zhang([email protected])
IETF 69#, CCAMP WG Chicago 07/24/2007
Backgroud
 Extensions to OSPF-TE is already a WG I-D.
 Intra-AS TE links advertisement is OK.
 RFC3784 has defined how to advertise the intra-area TE links.
 RFC4205 and ISIS-TE-v3 define the similar extensions.
 Inter-AS TE links advertisement is not defined yet (ISIS).
 Extensions to ISIS-TE for inter-AS TE
 Optimization for selection of AS exit points,
 Identifying the AS and ASBR reached through each exit point.
 Such inter-AS TE link information includes:
 List of all inter-AS TE links for the local AS
 TE properties of each inter-AS TE link
 AS number of the neighboring AS and identity of the neighboring ASBR connected to by
each inter-AS TE link
 Per-domain and BRPC both need such inter-AS TE link information
IETF 69#, CCAMP WG Chicago 07/24/2007
Proposal
Extensions to ISIS-TE
Two new sub-TLVs are added to the Extended IS Reachability TLV.
 Remote AS number sub-TLV
 Remote ASBR ID sub-TLV
A new TLV is defined. ( the inter-AS reachability TLV )
 Same semantic and formats as the Extended IP Reachability TLV
Using Up/down bit, facilitate distribution inter-AS reachability info
between tow levels
 Inter-AS reachability TLV with two sub-TLVs
Remote AS number sub-TLV
Remote ASBR ID sub-TLV
IETF 69#, CCAMP WG Chicago 07/24/2007
Next step
Need more comments and feedback from WG
Solicit inputs from ISIS
Accept this draft as a WG I-D?
IETF 69#, CCAMP WG Chicago 07/24/2007
Comments?
Thanks!
IETF 69#, CCAMP WG Chicago 07/25/2007
PS:
Why Per-Domain needs inter-AS links?
Two typical scenarios:
Path Message
AS 2
AS 1
Ingress A1
LSR
B1
A2
AS 3
B3
C1
C3
B2
A3
B4
ERO
Scenario 1:
Locate Exit ASBR
based on AS
number of
downstream AS
AS2 loose
AS3 loose
Scenario 2:
Locate Exit ASBR
based on entry
ASBR of
downstream AS
IETF 69#, CCAMP WG Chicago 07/25/2007
C2
ERO
B1 loose
C1 loose
Egress
LSR
PS:
Why BRPC needs inter-AS links?
Typical computation scenario for BRPC
The traversed domains are assumed to be selected before path
computation: AS1->AS2->AS3
PCE2
PCE1
A2
Ingress A1
LSR
B1
PCE3
B3
C1
C3
AS 1
A3
B2
AS 2
B4
C2
Egress
LSR
AS 3
PCE3 and PCE2 need to select entry boundary nodes based on their
upstream AS number respectively.
PCE2 and PCE1 need to select exit boundary nodes that provide
connections to their downstream AS respectively.
IETF 69#, CCAMP WG Chicago 07/25/2007
PS:
Not to do
Not trying to distribute TE information from one AS within
another AS.
Not trying to distribute any form of TE reachability information
for destinations outside the AS
Not proposing any change to the PCE architecture or usage.
Not suggesting any TE aggregation.
IETF 69#, CCAMP WG Chicago 07/25/2007