Subject: Re: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard

From: Balaji Rajagopalan <[email-masked]>
Date: Wed, 1 Apr 2015 17:00:15 +0000

I seek a correction to the following text in section 3.2.1.4.

"
IGP Router ID: <snip> For an OSPFv2 "Pseudonode" representing a LAN,

      this contains the 4 octet Router-ID of the designated router (DR)
      followed by the 4 octet IPv4 address of the DR's interface to the
      LAN (8 octets in total) <snip>"

The reason I seek this change is, the transit link representation in OSPFv2 router-LSA does not contain the router-id of the DR (section 12.4.1.2 of RFC2328). So, BGP-LS has nowhere to derive Router-ID from.

Below are more details with an example.

The 'IGP router ID' field can appear either in ‘Local Node Descriptor’ or ‘Remote Node Descriptor’. Let’s consider the case in which this field appears in ‘Remote Node Descriptor’ in the following topology.

R1(1.1.1.1::10.10.10.1) <----L1----> R2 (2.2.2.2::10.10.10.2)

Where,
R1's router-id is 1.1.1.1, and L1 interface IP address is 10.10.10.1.
R2's router-id is 2.2.2.2, and L1 interface IP address is 10.10.10.2.
L1 is a LAN.
R1 is elected as the DR for L1.

There are four distinct unidirectional links in the topology above: R1->DR, DR->R1, R2->DR, and DR->R2. Let’s consider the link R2->DR. R2’s router LSA represents R2->DR link as follows: -

Advertising router:2.2.2.2
   Link ID: 10.10.10.1
   Link data:10.10.10.2
   Type:2 (Transit)

Note that the OSPF link representation above does not include the router-id of the DR, which is 1.1.1.1.

According to the text in section 3.2.1.4, BGP-LS requires us to represent R2->DR link as follows (considering only node descriptors of relevance to this discussion, and ignoring the remaining fields) : -

Local Node(IGP-Router-Id:2.2.2.2) -> Remote Node(IGP-Router-Id:1.1.1.1-10.10.10.1)

However, the OSPF representation of the above link in R2’s router LSA does not contain 1.1.1.1 at all. Therefore, BGP-LS has nowhere to derive ‘1.1.1.1’ from, for the link R2->DR.

The example in section 3.7 is at odds with the text in section 3.2.1.4, and represents the link as follows (which works perfectly): -

Local Node(IGP-Router-Id:2.2.2.2) -> Remote Node(IGP-Router-Id:10.10.10.1-10.10.10.1)

I suggest rewording the text in 3.2.1.4 as follows:

"
IGP Router ID: <snip> For an OSPFv2 "Pseudonode" representing a LAN,

      this contains the 4 octet IPv4 address of the DR's interface to the
      LAN, followed by any non-zero 4-octet number (8 octets in total) <snip>”

—
Balaji Rajagopalan

From: The IESG <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 19, 2015 at 1:10 AM
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard

The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'North-Bound Distribution of Link-State and TE Information using BGP'
  <draft-ietf-idr-ls-distribution-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2015-04-08. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   In a number of environments, a component external to a network is
   called upon to perform computations based on the network topology and
   current state of the connections within the network, including
   traffic engineering information.  This is information typically
   distributed by IGP routing protocols within the network.

   This document describes a mechanism by which links state and traffic
   engineering information can be collected from networks and shared
   with external components using the BGP routing protocol.  This is
   achieved using a new BGP Network Layer Reachability Information
   (NLRI) encoding format.  The mechanism is applicable to physical and
   virtual IGP links.  The mechanism described is subject to policy
   control.

   Applications of this technique include Application Layer Traffic
   Optimization (ALTO) servers, and Path Computation Elements (PCEs).

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ballot/

The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1864/

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 1 Apr 2015 17:41:51 +0000

Balaji,

This is an implementation issue based on the fact that you are deriving the BGP LS information from the LSAs rather than having the IGP install the normalized draft-ietf-idr-ls-distribution links. Given that the draft is with the IESG, I’m not sure we want to attempt to optimize it to your implementation and disruptive everyone else’s. If you are maintaining the LSAs in an OSPF LSDB type structure in BGP, you easily find the Network LSA and extract the advertising router.

Thanks,
Acee

From: Balaji Rajagopalan <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 1, 2015 at 1:00 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard

"

Where,

"

—
Balaji Rajagopalan

Abstract

---

From: Balaji Rajagopalan <[email-masked]>
Date: Thu, 2 Apr 2015 03:26:43 +0000

Hi Acee,

I also pointed out an inconsistency between the example in section 3.7 and the normative text in section 3.2.1.4. So, the draft needs a correction anyway.

The question is, which one needs to be corrected – section 3.7, or section 3.2.1.4.

IMHO, we should correct the normative text in section 3.2.1.4 to align with the example in section 3.7, as the example more closely reflects how OSPFv2 represents the link.

—
Balaji Rajagopalan

From: "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 1, 2015 at 11:11 PM
To: Balaji Rajagopalan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard

Balaji,

Thanks,
Acee

"

Where,

"

—
Balaji Rajagopalan

Abstract

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 2 Apr 2015 13:40:52 +0000

Hi Balaji,

As the IETF Routing Directorate reviewer of the this draft, I agree that it is far from perfect. However, it is very late in the review cycle and we have several implementations (refer to https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/). It is not the time to change it just to ease your implementation. See inline.

From: Balaji Rajagopalan <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 1, 2015 at 11:26 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard

Hi Acee,

Section 3.7 is not necessarily wrong. While this is not the best OSPF example, 10.1.1.1 may be both the IP interface address and the OSPF Router ID.

Are you familiar with OSPFv3? In OSPFv3, the Router-ID is used in the Router-LSA to identify the DR. Hence, if we were to change it, OSPFv3 would need to be handled separately.

Acee

—
Balaji Rajagopalan

Balaji,

Thanks,
Acee

"

Where,

"

—
Balaji Rajagopalan

Abstract

---

From: Balaji Rajagopalan <[email-masked]>
Date: Thu, 2 Apr 2015 16:52:29 +0000

Hi Acee,

Thanks for the detailed response. Please see inline.

Date: Thursday, April 2, 2015 at 7:10 PM

Hi Balaji,

[Balaji] FWIW, I represented JUNOS (one of the implementations listed in the above draft) at one of the inter-ops, where we did not test OSPF broadcast network type due to the same issue we’re discussing now; I had notified the protocol author of this issue at that time. But, I do agree with you – there is one more implementation (ODL) listed in the draft, although I don’t know how it was all verified, since I still see an inconsistency between 3.7 and 3.2.1.4. Please see below.

[Balaji] In the specific example described in section 3.7, the router-id is not the same as the interface IP address (although I see your point that they may be the same in some scenarios). Node1’s router-id is 11.11.11.11 and node2’s router-id is 33.33.33.34. In the example, the DR is represented as 10.1.1.1:10.1.1.1. ’10.1.1.1' is the interface IP address of the DR(Node1).

Per section 3.2.1.4, this example should represent the DR as 11.11.11.11:10.1.1.1.1.

So, I believe there is still a need to reconcile section 3.7 with 3.2.1.4. And, I’m tilting towards the behavior described in section 3.7 :-)

[Balaji] Since BGP-LS carries the ‘protocol’ type in the NLRI (which has different codes for OSPFv2 and OSPFv3), we can leave OSPFv3 representation as it is.

For that matter, I believe that BGP-LS should preserve the representation in the underlying protocol, if there is no good reason to change it. I understand that this is not an argument to make at this stage, but the inconsistency I reported above needs to be resolved. And, I would like to request that we resolve it using the principle that BGP-LS should not change the underlying protocol’s representation unnecessarily.

Thanks!

—
Balaji Rajagopalan