identifiers for mpls-tp
DESCRIPTION
Identifiers for MPLS-TP. George Swallow. Status. In Anaheim, draft was identified as a pre- req for G.8110.1 Incomplete draft was rushed to last call Changes in various Framework drafts as well as a volcano made it impossible to produce a quality draft in time for ITU meeting - PowerPoint PPT PresentationTRANSCRIPT
Identifiers for MPLS-TP
George Swallow
In Anaheim, draft was identified as a pre-req for G.8110.1
Incomplete draft was rushed to last call Changes in various Framework drafts as
well as a volcano made it impossible to produce a quality draft in time for ITU meeting
Now declaring that the draft is NOT in last call
Status
Incorporated most of the ITU liaison comments
Addressed many of the mail list issues Much rewriting for clarification Many comments have not been addressed
Changes in rev -02
Equated Interface (IF) to Access Point (AP) Clarified use of source and destination
◦ via notation in BNF◦ Noting that in a configured environment East and
West would be equivalent◦ Src/Dst terminology is inherent in GMPLS
Clarifications
LSP-num – 16 bit identifier as in RFC3209Unique within scope of tunnel
LSP-ID formed as local{Global-ID::node::Tun-ID}+remote{[Sp-ID]::node::Tun-ID}::LSP-ID◦ Canonical Format of LSP-ID
lower ([Sp-ID]::Node-ID) goes first◦ Compatible with GMPLS signaling
MPLS-TP LSP Identifiers
Primary motivation is to have a simple way of forming globally unique MEP-IDs
[Global-ID]::Node_ID::Tunnel_ID::LSP_ID Similar to Pseudowire Attachment Circuit ID It has also been pointed out that this will be
useful for signaling associated bi-directional lsp
Rationale for two Tunnel-IDs
Node A signals tunnel 5 to node B with an object requesting an associated bidirectional tunnel
Node B signals tunnel 7 to node B returning the object completing the association
This also raises the question of whether two LSP-IDs are needed
(I don’t think this is necessary for initial setup, but for regrooming it could be an issue)
Example of Associated Bidirectional LSP
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| A|---------|B C|---------|D E|---------|F |
| T-PE1 | | S-PE2 | | S-PE3 | | T-PE4 |
+-------+ +-------+ +-------+ +-------+
The identification for the Pseudowire is:AGI = AGI1
Src-Global_ID = GID1
Src-Node_ID = T-PE1
Src-AC_ID = AC1
Dst-Global_ID = GID1
Dst-Node_ID = T-PE1
Dst-AC_ID = AC4
MEP_ID at point A = AGI1::GID1:T-PE1::AC1
MIPs same LSPs
PW status from a S-PE is sent by the node
Pseudowire Maintenance PointsTentative resolution
Current Status: Two formatsGlobal-ID as per RFC5003ITU Carrier Code
Issue:Should these be combinable with all other
identifiers that need global uniquenessOr should some limits exist on mixing and matching
ITU and IP style IDs?Need to figure out exactly where these will get
used before deciding
Service Provider IDs
Many open issues – this is a partial list
1. IPv6
2. Support for all forms of IF-IDs allowed in GMPLS
3. Support for other PHOP formats for identifying Ifs
4. Two LSP-IDs as well as two tunnel-IDs
5. Do we need circuit-IDs as well as MEG-IDs
Other open Issues