ietf
[Top] [All Lists]

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

2015-04-03 10:30:28
Hi Acee,

Thanks for the detailed response. Please see inline.

From: "Acee Lindem (acee)" 
<acee(_at_)cisco(_dot_)com<mailto:acee(_at_)cisco(_dot_)com>>
Date: Thursday, April 2, 2015 at 7:10 PM
To: Balaji Rajagopalan 
<balajir(_at_)juniper(_dot_)net<mailto:balajir(_at_)juniper(_dot_)net>>, 
"ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>" 
<ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>>, Hannes Gredler 
<hannes(_at_)juniper(_dot_)net<mailto:hannes(_at_)juniper(_dot_)net>>
Cc: "idr(_at_)ietf(_dot_)org<mailto:idr(_at_)ietf(_dot_)org>" 
<idr(_at_)ietf(_dot_)org<mailto:idr(_at_)ietf(_dot_)org>>
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 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.

[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.


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.

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.

[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 :-)



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.

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.

[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