Subject: [Idr] I-D Action: draft-ietf-idr-aigp-17.txt

From: [email-masked]
Date: Tue, 08 Apr 2014 07:11:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

        Title           : The Accumulated IGP Metric Attribute for BGP
        Authors         : Pradosh Mohapatra
                          Rex Fernando
                          Eric C. Rosen
                          James Uttaro
	Filename        : draft-ietf-idr-aigp-17.txt
	Pages           : 15
	Date            : 2014-04-08

Abstract:
   Routing protocols that have been designed to run within a single
   administrative domain ("IGPs") generally do so by assigning a metric
   to each link, and then choosing as the installed path between two
   nodes the path for which the total distance (sum of the metric of
   each link along the path) is minimized.  BGP, designed to provide
   routing over a large number of independent administrative domains
   ("autonomous systems"), does not make its path selection decisions
   through the use of a metric.  It is generally recognized that any
   attempt to do so would incur significant scalability problems, as
   well as inter-administration coordination problems.  However, there
   are deployments in which a single administration runs several
   contiguous BGP networks.  In such cases, it can be desirable, within
   that single administrative domain, for BGP to select paths based on a
   metric, just as an IGP would do.  The purpose of this document is to
   provide a specification for doing so.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-aigp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-idr-aigp-17

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aigp-17

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Vitkovský Adam <[email-masked]>
Date: Thu, 10 Apr 2014 14:55:54 +0000

Hello everybody, 

I would like to clarify my understanding on couple of the points below. I'm sorry if I query about something that has been discussed already. 
Thank you very much for your time.

3.4.1. Originating the AIGP Attribute. 
A BGP speaker MUST NOT add the AIGP attribute to any route whose path leads outside the "AIGP administrative domain" to which the BGP speaker belongs. 
The route is an EBGP-learned route whose AS_PATH contains only ASes that are in the same AIGP Administrative Domain as the BGP speaker. 

- Wouldn't it be helpful to use AIGP metric to find best exit(s) from an administrative domain please? 

3.4.1. Originating the AIGP Attribute. 
When a BGP speaker R is redistributing into BGP an IGP route to address prefix P, the IGP will have computed a "distance" from R to P.  This distance MAY be assigned as the value of the AIGP TLV. 

- So with AIGP, e.g CEs connected to MPSL backbone would be able to make the routing decisions based on the whole CE to CE path and that is regardless of the CE to PE routing protocol. 
- Do I understand it correctly please? 

3.4.3. Modifications by a Non-Originator. 
Suppose R1 changes the Next Hop of the route from R2 to R1, and R1's route to R2 is either (a) a BGP-learned route or (b) a static route that requires recursive next hop resolution. 

- I'd like to clarify my understanding of this section please. 
- Do I understand it correctly that this section is concerning the case of Hierarchical MPLS for InterAS MPLS VPN Opt.10C or CsC with use of RFC3107 please? 
- In other words case where the NH for a VPN prefix (egress PE BGP RID) is known via BGP from ASBR -and path to that NH is recursively found via IGP path to ASBR. 
- So in this case the AIGP metric to NH would be a sum of AIGP metric advertised by the ASBR and the IGP metric to that ASBR. 

- However if VPNv4/v6 session carries AIGP metric from CE to CE -the AIGP metric might consist of the AIGP metric between ingress and egress PEs and the AIGP metric derived from the IGP distance from PE to CE. 

4. Decision Process. 
The procedures in this section MUST be executed BEFORE any of the tie breaking procedures described in [BGP] section 9.1.2.2 are executed. 

- So for routes with AIGP TLV, AIGP metric is considered first (so BGP basically becomes RIP) and only if there is a tie the regular BGP decision process is invoked afterwards. 
- Do I understand it correctly please? 

4.2. When the Route to the Next Hop has an AIGP attribute. 

- In hierarchical MPLS it would be great if we could chose based either on the whole: local igp metric to ASBR-NH + AIGP metric or just based on AIGP itself ignoring the local igp metric to ASBR-NH "sort of" OSPF's E1 to E2. 

adam