BGP Traffic Engineering Attribute draft-fedyk-bgp-te-attribute-03.txt

1. BGP Traffic Engineering Attributedraft-fedyk-bgp-te-attribute-03.txt Yakov Rekhter, Don Fedyk, Hamid Ould-Brahim IETF 70th, Vancouver Meeting, CCAMP, December 2007

2. Some History of BGP-TE attribute • IETF 67th November 2006 presented to L1VPN WG; chairs requested the draft to be presented to IDR WG. • IETF 68th (March 2007) presented to IDR WG, incorporated comments, no objections from IDR WG. • IETF 68th CCAMP chair proposed that the best home for this work is CCAMP (see IDR IETF68th meeting minutes). • And volunteered to bring the ID to CCAMP WG. • March 2007 CCAMP chair proposed to merge the draft with draft-vasseur-ccamp-ce-ce-te-03.txt (see next slide for more). • The latter draft was presented neither to L3VPN nor IDR WGs so far • BGP-TE attribute is a normative reference in L1VPN BGP auto discoverydraft. • draft-ietf-l1vpn-bgp-auto-discovery has passed L1VPN WG last call (October 2007) • September 2007 CCAMP chair suggested to re-evaluate suitability of the draft for CCAMP WG. • October 1st 2007 authors of BGP-TE attribute asked CCAMP chairs to accept the draft as a CCAMP WG document. • December 2007: CCAMP chair positions the whole problem to be just “Distribution of TE information from outside ASes”. IETF70th, Vancouver Dec 2007

3. Why merge is not appropriate • Merging draft-fedyk-bgp-te-attribute and draft-vasseur-ccamp-ce-ce-te is not appropriate: • The former specifies encoding of a BGP attribute. • The latter specifies one possible use of such attribute. • Without describing the format of the attribute (for future revisions of the document). • BGP attributes are defined in their own documents with pointers to documents that specify usage of such attributes. • E.g., BGP Extended Community attribute. • No compelling reasons to change this. • With this in mind we should consider discussion on merging the two drafts closed with the resolution not to merge them. IETF70th, Vancouver Dec 2007

4. What TE information to carry ? (1) • Debate on the CCAMP mailing list: • Agreement on the fact that TE information needs to be captured in a new BGP TE attribute. • Disagreement is mainly on whether • (a) to carry all and exactly the same TLVs as in OSPF-TE or • (b) only a (proper) subset of the information carried by all these TLVs. IETF70th, Vancouver Dec 2007

5. What TE information to carry ? (2) • Currently there is only one application that is an IETF WG (L1VPN WG) document that requires BGP to distribute traffic engineering information. • draft-vasseur-ccamp-ce-ce-te is a proposal with applicability to L3VPNs. • Traffic engineering information required by L1VPN forms a (proper) subset of the information carried in all the TE TLVs carried in OSPF Opaque LSA. • Moreover, some of the information carried in the TE TLVs of OSPF Opaque LSAs is carried in BGP as part of L1VPN NLRI • Carrying the same information in the BGP-TE attribute is useless • The information carried in BGP-TE attribute reflects L1VPN usage of this attribute. • Authors of draft-vasseur-ccamp-ce-ce-te want to carry all and exactly the same TLVs as in OSPF-TE. • If the intent is to carry all the OSPF-TE TLVs, as carried in OSPF opaque LSA “as is”, then why not use OSPF ? • OSPF already provides mechanism to carry opaque LSA. • Why BGP would be a better transport for opaque LSA then OSPF ? IETF70th, Vancouver Dec 2007

6. TE Information (OSPF for example) MPLS RFC 3630 GMPLS Depreciates two fields 1 Link type (1 octet) 2 Link ID (4 octets) 3 Local interface IP address (4 octets) 4 Remote interface IP address (4 octets) 5 Traffic engineering metric (4 octets) 6 Maximum bandwidth (4 octets) 7 Maximum reservable bandwidth (4 octets) 8 Unreserved bandwidth (32 octets) 9 Administrative group (4 octets) GMPLS RFC 4203 OR 11 Link Local/Remote Identifiers (8 octets) 14 Link Protection Type (4 octets) 15 Interface Switching Capability Descriptor (variable) 16 Shared Risk Link Group (variable) draft-fedyk-bgp-te-attribute-03.txtNew BGP attribute (BGP-TE Attribute) Interface Switching Capability Descriptor (see RFC4203, RFC4205) BGP already includes the address in NRLI (3, 4 or 11) for L1VPN BGP MED may carry the TE Metric As indicated in the mailing list other information can be added if there is WG consensus IETF70th, Vancouver Dec 2007

7. BGP-TE Attribute usage • The information carried in BGP-TE attribute reflects L1VPN usage of this attribute. • The authors are willing to include certain guidelines for future use of the attribute. • Provided these guidelines are developed using IETF consensus process. IETF70th, Vancouver Dec 2007

8. More on BGP-TE usage by L1VPN • Viewing L1VPN usage of BGP-TE attribute as just “distribution of TE information outside ASes” does not adequately reflect the application. • For one thing, L1VPN deals with multiple routing/addressing realms. • “Area” or “AS” as scopes for “flooding” TE information, while relevant in the context of distribution of TE information outside AS, is not applicable in the context of L1VPN. • PE with a given L1VPN attached to it redistributes the reachability/membership information (and the TE information as well) to all other PEs that have that L1VPN. • Has nothing to do with areas and/or ASes. IETF70th, Vancouver Dec 2007

9. Summary • The “Distribution of TE information from outside ASes” issues brought in CCAMP are unrelated/non-applicable to the use of BGP-TE attribute in L1VPN WG. • BGP-TE attribute is a normative reference in L1VPN BGP auto discovery draft. • draft-ietf-l1vpn-bgp-auto has passed L1VPN WG last call (October 2007). • No progress of draft-fedyk-bgp-te-attribute in CCAMP. • Lack of progress in BGP-TE in CCAMP blocks progress of draft-ietf-l1vpn-bgp-auto-discovery. • Proposal: Move draft-fedyk-bgp-te-attribute to L1VPN WG. IETF70th, Vancouver Dec 2007