Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Alexander Okonnikov]

Hi Owen,

RFC 2328 doesn't require MTUs to be matched. It unambiguously says that 
"Interface MTU ... is larger than the router can accept on the receiving 
interface ...". RFC 2328 even doesn't say something about MTU of receiving 
interface. So, if implementation on router A performs check for MTU mismatch 
(i.e. from router A point of view they are expected to be equal), it is 
misinterpretation of RFC 2328.

Yes, RFC 5838 says something another - it, for unknown reason, says, that RFC 
2328 says that DBD to be rejected if Interface MTU value in DBD is greater than 
the receiving interface's MTU. I don't know why it is needed to compare those 
two values, but, again, even in this case there is no requirement for MTU 
matching. There is requirement for to be not larger, and this is different 
requirement. Please, correct me if I'm wrong.

On the other hand, while behavior of implementation J on router B is somewhat 
different from RFC 2328/RFC 5838, it is not disruptive, but only in case that 
behavior of router A in part of processing received DBD would be implemented 
correctly.

Thank you.

> 21 сент. 2023 г., в 22:49, Owen DeLong  написал(а):
> 
> 
> 
>> On Sep 21, 2023, at 10:50, Alexander Okonnikov 
>>  wrote:
>> 
>> Hi WG,
>> 
>> Regarding the errata - the errata claims that cause of it is the bug in an 
>> implementation, sending DBD with Interface MTU = 0. Maybe it is so, but it 
>> seems that real bug is in implementation(s), receiving and dropping such DPD.
>> 
>> Both RFCs - 5838 and 5340 - inherit rules for receiving DBD from RFC 2328. 
>> RFC 2328 says follow (section 10.6):
>> 
>> "... If the Interface MTU field in the Database Description packet indicates 
>> an IP datagram size that is larger than the router can accept on the 
>> receiving interface without fragmentation, the Database Description packet 
>> is rejected. ..."
>> 
>> Obviously, 0 is not larger than IP datagram size that can be accepted on the 
>> receiving interface. I guess that the size is greater than 0, but, even if 
>> it is equal to 0, then 0 (Interface MTU value in DBD) is not larger than 0 
>> (acceptable size of receiving datagram).
>> 
> 
> The problem isn’t rejection due to MTU too large, but rejection due to MTU 
> mismatch.
> 
> Router A from virtually any other vendor sees MTU on (e.g. GRE) interface as 
> 1476 and sends 1476 in DBD.
> Router B from vendor J has MTU on interface as 1476, but instead sends 0 in 
> DBD.
> Router A detects MTU mismatch and shuts down the session unless configured 
> for ignore-mtu-mismatch.
> 
> So the discussion of what routers should do if the MTU is too large is kind 
> of not relevant to the errata.
> 
>> Now regarding essense of the problem. I don't agree with the errata - it is 
>> clear enough that 'virtual links' are mentioned in context of OSPF, hence, 
>> 'OSPF virtual links' rather than some other 'virtual links' or 'IP virtual 
>> links' are implied there.
> 
>> But, I think that decision taken in the subjected implementation is good 
>> trade-off for tunnel interfaces, which doesn't violate procedure for 
>> receiver side, and, thus, even doesn't require implementation of 
>> 'ignore-mtu' functionality on receiving side. Actually, issues, related to 
>> path MTU discovery nature and applicable to OSPF virtual links, are equally 
>> applicable to OSPF interfaces deployed as tunnels. I don't see how DBD 
>> Interface MTU can help in solving problems with possible fragmentation, PMTU 
>> blackholes on transit and so on. My view is that actual problem, which DBD 
>> Interface MTU is intended to mitigate, is on tunnel egress OSPF router. Due 
>> to nature of tunnels, tunneled IP datagrams can ingress OSPF router via any 
>> of multiple transport interfaces, each of which may have its own MRU. What 
>> will be MRU of tunnel interface in this case? It is OK if all those 
>> transport interfaces have the same MRU value, and tunnel interface MRU will 
>> be stable, but what if it is not the case? We would need to adjust tunnel 
>> MRU every time some transport interface added/removed. It seems that 
>> omitting MRU check via DBD Interface MTU for tunnel interfaces would be more 
>> or less good solution which doesn't require OSPF spec modification (beside 
>> writing '0' into Interface MTU field). Any way, current OSPF (per my 
>> knowledge) doesn't provide mechanism for OSPF DBD receiver to signal actual 
>> MRU to OSPF DBD sender, and thus rejecting DBD on receive doesn't look 
>> better than broken PMTUD (PMTUD blackhole).
> 
> I don’t disagree with your point here, but my point is that the RFC should 
> 

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Alexander Okonnikov]

Hi WG,

Regarding the errata - the errata claims that cause of it is the bug in an 
implementation, sending DBD with Interface MTU = 0. Maybe it is so, but it 
seems that real bug is in implementation(s), receiving and dropping such DPD.

Both RFCs - 5838 and 5340 - inherit rules for receiving DBD from RFC 2328. RFC 
2328 says follow (section 10.6):

"... If the Interface MTU field in the Database Description packet indicates an 
IP datagram size that is larger than the router can accept on the receiving 
interface without fragmentation, the Database Description packet is rejected. 
..."

Obviously, 0 is not larger than IP datagram size that can be accepted on the 
receiving interface. I guess that the size is greater than 0, but, even if it 
is equal to 0, then 0 (Interface MTU value in DBD) is not larger than 0 
(acceptable size of receiving datagram).

Also, RFC 5838 contains (section 2.7) incorrect rephrasing of RFC 2328:

"... As specified in Section 10.6 of [OSPFV2], the Database Description packet 
will be rejected if the MTU is greater than the receiving interface's MTU for 
the address family corresponding to the instance. ..."

"Is larger than the router can accept on the receiving interface" (RFC 2328) 
and "is greater than the receiving interface's MTU" (RFC 5838) - strictly 
speaking, two ones are not the same. My understanding of goal of the procedure 
in section 10.6 of RFC 2328 is to ensure that lower layer maximum receive unit 
value (Maximum Receive Unit in PPP, Maximum Frame Size in IEEE 802.3, and so 
on) is enough to accept IP datagrams with size, specified in Interface MTU of 
DBD message (of course, with needed math for corresponding lower layer 
encapsulations), such that there would not be blackholing on lower layer on 
receipt. I don't see reason to check Interface MTU from DBD against MTU of 
receiving interface. MTU of receiving interface is not the same as MRU of 
receiving interface, and MTU of the interface is irrelevant to receiving 
datagrams.

RFC 1812 says follow in section 3.3.4:

"... However, a router SHOULD be willing to receive a packet as large as the 
maximum frame size even if that is larger than the MTU. ..."

It is common that for regular interfaces MRU usually eqauls to MTU. But for 
tunnels this equality doesn't hold, due to, e.g. assymetric routing. And even 
for regular interfaces, while MRU=MTU usually, strictly speaking two ones are 
not have to be equal.

By the way, "without fragmentation" in 10.6 of RFC 2328 looks unclear for me. 
I'm not aware about fragmentations performed on receiving, and do you? Either 
this phrase inapplicable for receiving IP datagrams, or, probably, 'without 
reassembly' was assumed there?

Now regarding essense of the problem. I don't agree with the errata - it is 
clear enough that 'virtual links' are mentioned in context of OSPF, hence, 
'OSPF virtual links' rather than some other 'virtual links' or 'IP virtual 
links' are implied there. But, I think that decision taken in the subjected 
implementation is good trade-off for tunnel interfaces, which doesn't violate 
procedure for receiver side, and, thus, even doesn't require implementation of 
'ignore-mtu' functionality on receiving side. Actually, issues, related to path 
MTU discovery nature and applicable to OSPF virtual links, are equally 
applicable to OSPF interfaces deployed as tunnels. I don't see how DBD 
Interface MTU can help in solving problems with possible fragmentation, PMTU 
blackholes on transit and so on. My view is that actual problem, which DBD 
Interface MTU is intended to mitigate, is on tunnel egress OSPF router. Due to 
nature of tunnels, tunneled IP datagrams can ingress OSPF router via any of 
multiple transport interfaces, each of which may have its own MRU. What will be 
MRU of tunnel interface in this case? It is OK if all those transport 
interfaces have the same MRU value, and tunnel interface MRU will be stable, 
but what if it is not the case? We would need to adjust tunnel MRU every time 
some transport interface added/removed. It seems that omitting MRU check via 
DBD Interface MTU for tunnel interfaces would be more or less good solution 
which doesn't require OSPF spec modification (beside writing '0' into Interface 
MTU field). Any way, current OSPF (per my knowledge) doesn't provide mechanism 
for OSPF DBD receiver to signal actual MRU to OSPF DBD sender, and thus 
rejecting DBD on receive doesn't look better than broken PMTUD (PMTUD 
blackhole).

Sorry in advance for long complicated speech.

Thanks.

> 21 сент. 2023 г., в 12:49, Acee Lindem  написал(а):
> 
> 
> 
>> On Sep 20, 2023, at 7:02 PM, Owen DeLong  wrote:
>> 
>> Given what I have seen, I would argue for semantics of 0=valid only on 
>> virtual link. On others, must not be 0 and must reflect actual interface MTU.
> 
> If you feel further specification is necessary, it should be done in a draft 
> rather than an Errata (as John already mentioned). However, note that this is 
> a 

Re: [Lsr] Regarding OSPFv3 VPN Domain Type

[Alexander Okonnikov]

Hi Acee, Rajesh,

RFC 6565 states that the same communities, defined in RFC 4577, are reused.

Just before the text, quoted by Rajesh, there is statement:

"The BGP Extended Communities attributes defined in [RFC4577] are reused for 
convenience."

RFC 4577 defines sub-type 0x05 and also refers to RFC 4360, where 0x00 and 0x01 
types are defined. Only gap, that I notice, is that RFC 4360 (and RFC 4577) 
mentions type 0x02, but doesn't define that type and doesn't point to reference 
of its definition (it was defined later in RFC 5668).

> 17 сент. 2021 г., в 17:15, Acee Lindem (acee) 
>  написал(а):
> 
> Hi Rajesh, 
>  
> This is the extended community type and RFC 6565 really should have had some 
> references for this - It took me a good 15-20 minutes to recall all the 
> details. The first octet specifies the extended community type of domain ID 
> as defined in https://www.rfc-editor.org/rfc/rfc7153.html#section-5.1.1 
> 
>  
> TYPE VALUE   NAME
>  
>   0x00 Transitive Two-Octet AS-Specific Extended
>Community (Sub-Types are defined in the
>"Transitive Two-Octet AS-Specific Extended
>Community Sub-Types" registry)
>  
>   0x01 Transitive IPv4-Address-Specific Extended
>Community (Sub-Types are defined in the
>"Transitive IPv4-Address-Specific Extended
>Community Sub-Types" registry)
>  
>   0x02 Transitive Four-Octet AS-Specific Extended
>Community (Sub-Types are defined in the
>"Transitive Four-Octet AS-Specific Extended
>Community Sub-Types" registry)
>  
>  
> The second octet (0x05) is the registered sub-type value for the OSPF Domain 
> Identifier. See https://www.rfc-editor.org/rfc/rfc4577.html#page-10 
> .
>  
> Hope this helps,
> Acee
>  
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Rajesh M mailto:rajesh.i...@gmail.com>>
> Date: Friday, September 17, 2021 at 5:44 AM
> To: "lsr@ietf.org " mailto:lsr@ietf.org>>
> Subject: [Lsr] Regarding OSPFv3 VPN Domain Type
>  
> Hi All,
>  
> For OSPFv3 from RFC 6565, section 4.4, it is mentioned that 2-byte type field 
> in the attribute.
> May I know what three different types 0x0005, 0x0105 0x0205 represent?
>  
>OSPF Domain Identifier Extended Communities Attribute
>  
>Each OSPFv3 Instance within a VRF MUST have a Domain ID.  The Domain
>ID is configured per OSPFv3 Instance.  The OSPFv3 Domain ID is a
>6-byte number, and its default value is 0.  This attribute has a
>2-byte type field, encoded with a value of 0x0005, 0x0105, or 0x0205.
>  
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Type Value   |Domain Identifier  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Domain Identifier Cont.   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>  The OSPF Domain Identifier Extended Communities Attribute
>  
> Thanks & Regards,
> Rajesh
>  
>  
>  
> ___
> Lsr mailing list
> Lsr@ietf.org 
> https://www.ietf.org/mailman/listinfo/lsr 
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Link Data value for Multi-area links

[Alexander Okonnikov]

Hi Acee,

RFC 5185 says that interface data structure is created for each multi-area 
adjacency. I guess that we are not allowed to allocate several ifIndex values 
for the same IP interface, because it is property of router's interface, not 
OSPF interface. Hence, we have several OSPF interfaces with the same ifIndex in 
unnumbered case and, thus, ambiguity in Interface table. The same for numbered 
- we have IP interface address (one), which is the same for multiple OSPF 
interfaces, and we again obtain ambiguity. Per my understanding advertising 
neighbor's IP address (or ifIndex) in Link Data doesn't help here.

> 30 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp) 
>  написал(а):
> 
> The oddnes is that the architecture decision in RFC5185 to select 
> remote-ip-address instead of local-ip-address for the ‘Link Data’ is making 
> things much more complicated.
> I am surprised to see that using the remote-ip-address is seen as the 
> ‘better’ choice as selecting local-ip-address. To me it seems as a worse 
> choice.
>  
> A question that was asked: How router will be able to match Link TLV (RFC 
> 3630) to corresponding Link in Router LSA?
>  
> Answer:
> For unnumbered links we can match Link TLV with Router TLV using the IfIndex 
> when there is no stub type 3 link (=easy)
> For numbered:
> we must first look if the there is a stub type 3 link
> If stub type 3 exists, then the RFC3630 local ip address must be used to 
> identify the correspond link within the router TLV to the neighbor
> If the stub type 3 link did not exist in Router TLV link, then the maybe the 
> link is unnumbered, and we try to match upon IfIndex… This may give a match 
> or no match
> If there is no match, then maybe the link is MADJ and we must use the RFC3630 
> remote IP address to match upon the Link Data
> = over-complex. (If we used  for RFC5185 ‘Link Data = local ip address’ then 
> (2) would given answer directly)
>  
> In addition, for a router it is much simpler to learn and advertise 
> local-ip-address in Router LSAs then using a remote-ip-address.
> I also believe that if we want to search something in TEDB after receiving a 
> TE Link TLV. How can we identify from the TE Link TLV if multi-area or not 
> multi-area? If we can not, then how can we create the correct key?
>  
> Looking at the above, the choice of using remote-ip-address for RFC5185 Link 
> Data seems not the best design that we can do, and is adding OSPF complexity 
> without benefits.
>  
> Should this not be corrected in RFC5185 and simply use local-ip-address 
> instead of the remote-ip-address for Multi-area Link Data and avoid the 
> additional unnecessary complexity the current RFC for numbered links?
>  
> Brgds,
> G/
>  
>  
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: Monday, November 30, 2020 18:01
> To: Alexander Okonnikov ; Peter Psenak 
> (ppsenak) 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Link Data value for Multi-area links
>  
> Hi Alex, 
>  
> Multi-Area interface disambiguation is required to support the OSPF MIB as 
> specified in RFC 4750. The table indexing doesn’t include the area. For 
> example:
>  
> --  OSPF Interface Table
>  
>   ospfIfTable OBJECT-TYPE
>SYNTAX   SEQUENCE OF OspfIfEntry
>MAX-ACCESS   not-accessible
>STATUS   current
>DESCRIPTION
>   "The OSPF Interface Table describes the interfaces
>   from the viewpoint of OSPF.
>   It augments the ipAddrTable with OSPF specific information."
>REFERENCE
>   "OSPF Version 2, Appendix C.3  Router interface
>   parameters"
>::= { ospf 7 }
>  
>   ospfIfEntry OBJECT-TYPE
>SYNTAX   OspfIfEntry
>MAX-ACCESS   not-accessible
>STATUS   current
>DESCRIPTION
>   "The OSPF interface entry describes one interface
>   from the viewpoint of OSPF.
>  
>   Information in this table is persistent and when this object
>   is written the entity SHOULD save the change to non-volatile
>   storage."
>INDEX { ospfIfIpAddress, ospfAddressLessIf }
>::= { ospfIfTable 1 }
>  
> Note that if you really want to support this optimally, you could use a 
> separate subnet pre-area and have adjacencies on secondary addresses. My 
> Redback/Ericsson implementation allowed for this.   
>  
> Thanks,
> Acee
>  
>  
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Alexander Okonnikov  <mailto:alexander.okonni...@gmail.com>>
> Date: Monday, November 30, 2020 at 5:27 AM
> To: "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>
> C

Re: [Lsr] Link Data value for Multi-area links

[Alexander Okonnikov]

Hi Peter,

> 30 нояб. 2020 г., в 12:56, Peter Psenak  написал(а):
> 
> Hi Alex,
> 
> On 27/11/2020 13:49, Alexander Okonnikov wrote:
>> Hi Peter,
>> Which kind of ambiguity is meant? In case of numbered point-to-point each 
>> link has its own unique IP address, so there is no ambiguity.
>> Per my understanding this problem has appeared due to follow reasons:
>> 1) In old versions of the draft (up to -05) it was proposed that multi-area 
>> links are treated as unnumbered. ifIndex to be encoded in Link Data field, 
>> irrespectively whether interface has its own IP address (numbered) or borrow 
>> it (unnumbered);
>> 2) From -06 to -08 multi-area links are still treated as unnumbered, but if 
>> interface is numbered, then IP address of the neighbor (rather than local 
>> one) to be encoded into Link Data, in order to make the link look like 
>> unnumbered;
>> 3) In version -09 of the draft and in RFC 5185 itself there is no more 
>> mentions that multi-area link to be treated as unnumbered. Rather, another 
>> approach is used - if router's interface is numbered, then link is also 
>> numbered; if router's interface is unnumbered, then link is unnumbered. The 
>> rule that specifies omitting corresponding type 3 link is added. Mention of 
>> 'unnumbered' link is also removed from section 3 in RFC 5185. >
>> Hence, in version -09 with removing unnumbered nature of multi-area links 
>> Link Data for numbered links had to be changed from Neighbor's IP address to 
>> own IP address, as it is specified in RFC 2328. From perspective of other 
>> routers this link can be treated as numbered or unnumbered, depending on 
>> configuration of neighbor's corresponding interface.
> 
> you are free to advertise the link as unnumbered. RFC5185 is not mandating to 
> send IP address really.

The same valid for numbered ones. I.e. I'm free to advertise the link as 
numbered. This is straightforward when the link is numbered indeed. And if we 
would prefer to have deal with unnumbered interfaces, we would not need RFC 
5185 (section 1.2).

>> One question - how neighboring router will perform next-hop calculation (in 
>> case it needs to do so)? If neighbor is configured with numbered interface, 
>> it will treat Link Data as IP next hop, which will be its own IP interface 
>> address.
>> Another question - how router will be able to match Link TLV (RFC 3630) to 
>> corresponding Link in Router LSA? For example, we want to calculate RSVP-TE 
>> LSP based on IGP metric (RFC 3785) and thus router needs to match IGP link 
>> to TE link.
> 
> I don't believe you are going to do any traffic engineering over a multi-area 
> adjacency. MADJ is there to address the OSPF route preference rules that may 
> lead to sub-optimal routing. MADJ link is not advertised for TE purposes.

Why not? We need multi-area configuration and at the same time we need ability 
to build intra-area RSVP-TE LSPs within each of areas. And what about 
calculating IP next hop? Which compatibility is meant in section 3?

> thanks,
> Peter

Thank you.

>> Thank you.
>>> 27 нояб. 2020 г., в 14:50, Peter Psenak  написал(а):
>>> 
>>> Alexander,
>>> 
>>> On 26/11/2020 17:58, Alexander Okonnikov wrote:
>>>> Hi WG,
>>>> RFC 5185 says that Neighbor's IP address to be encoded into Link Data 
>>>> field. Per RFC 2328 router's own IP address to be encoded into Link Data. 
>>>> What is the reason to advertise neighbor's IP address for multi-area links 
>>>> and not local IP address? It seems like bug. Could someone comment on this?
>>> 
>>> Advertising a neighbor address/ifindex helps to eliminate ambiguity in case 
>>> of parallel point-to-point adjacencies. It's not perfect, but that's how it 
>>> was specified. So it's not a bug.
>>> 
>>> thanks,
>>> Peter
>>> 
>>>> Thanks in advance.
>>>> ___
>>>> Lsr mailing list
>>>> Lsr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Link Data value for Multi-area links

[Alexander Okonnikov]

Hi Peter,

Which kind of ambiguity is meant? In case of numbered point-to-point each link 
has its own unique IP address, so there is no ambiguity.

Per my understanding this problem has appeared due to follow reasons:

1) In old versions of the draft (up to -05) it was proposed that multi-area 
links are treated as unnumbered. ifIndex to be encoded in Link Data field, 
irrespectively whether interface has its own IP address (numbered) or borrow it 
(unnumbered);

2) From -06 to -08 multi-area links are still treated as unnumbered, but if 
interface is numbered, then IP address of the neighbor (rather than local one) 
to be encoded into Link Data, in order to make the link look like unnumbered;

3) In version -09 of the draft and in RFC 5185 itself there is no more mentions 
that multi-area link to be treated as unnumbered. Rather, another approach is 
used - if router's interface is numbered, then link is also numbered; if 
router's interface is unnumbered, then link is unnumbered. The rule that 
specifies omitting corresponding type 3 link is added. Mention of 'unnumbered' 
link is also removed from section 3 in RFC 5185.

Hence, in version -09 with removing unnumbered nature of multi-area links Link 
Data for numbered links had to be changed from Neighbor's IP address to own IP 
address, as it is specified in RFC 2328. From perspective of other routers this 
link can be treated as numbered or unnumbered, depending on configuration of 
neighbor's corresponding interface.

One question - how neighboring router will perform next-hop calculation (in 
case it needs to do so)? If neighbor is configured with numbered interface, it 
will treat Link Data as IP next hop, which will be its own IP interface address.

Another question - how router will be able to match Link TLV (RFC 3630) to 
corresponding Link in Router LSA? For example, we want to calculate RSVP-TE LSP 
based on IGP metric (RFC 3785) and thus router needs to match IGP link to TE 
link.

Thank you.

> 27 нояб. 2020 г., в 14:50, Peter Psenak  написал(а):
> 
> Alexander,
> 
> On 26/11/2020 17:58, Alexander Okonnikov wrote:
>> Hi WG,
>> RFC 5185 says that Neighbor's IP address to be encoded into Link Data field. 
>> Per RFC 2328 router's own IP address to be encoded into Link Data. What is 
>> the reason to advertise neighbor's IP address for multi-area links and not 
>> local IP address? It seems like bug. Could someone comment on this?
> 
> Advertising a neighbor address/ifindex helps to eliminate ambiguity in case 
> of parallel point-to-point adjacencies. It's not perfect, but that's how it 
> was specified. So it's not a bug.
> 
> thanks,
> Peter
> 
>> Thanks in advance.
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Link Data value for Multi-area links

[Alexander Okonnikov]

Hi WG,

RFC 5185 says that Neighbor's IP address to be encoded into Link Data field. 
Per RFC 2328 router's own IP address to be encoded into Link Data. What is the 
reason to advertise neighbor's IP address for multi-area links and not local IP 
address? It seems like bug. Could someone comment on this?

Thanks in advance.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Calculating OSPF external routes for non-zero FA

[Alexander Okonnikov]

Hi Acee,

Got it now. We don't know in advance whether there are other ASBRs which, while 
having connectivity to FA, have external routing information.

Thank you for explanation!

> 1 марта 2019 г., в 16:41, Acee Lindem (acee)  написал(а):
> 
> Hi Alexander, 
> If the ASBR is not reachable, the AS-External LSA could be stale and the 
> route it originally advertised could be unreachable or administrative 
> prohibited irrespective of the reachability of the forwarding address.
> Thanks,
> Acee
> 
> On 3/1/19, 8:16 AM, "Lsr on behalf of Alexander Okonnikov" 
>  wrote:
> 
>Hi WG,
> 
>I don't know whether the problem below is known already, but I have not 
> found neither update nor corresponding errata for RFC 2328. RFC 2328, section 
> 16.4 says:
> 
>"(3) ...  Look up the routing table entries (potentially one per attached 
> area) for the AS boundary router (ASBR) that originated the LSA. If no 
> entries exist for router ASBR (i.e., ASBR is unreachable), do nothing with 
> this LSA and consider the next in the list.
> 
>Else, this LSA describes an AS external path to destination N.  Examine 
> the forwarding address specified in the AS-external-LSA.  This indicates the 
> IP address to which packets for the destination should be forwarded. ..."
> 
>and
> 
>"... If the forwarding address is non-zero, look up the forwarding address 
> in the routing table.[24] The matching routing table entry must specify an 
> intra-area or inter-area path; if no such path exists, do nothing with the 
> LSA and consider the next in the list. ..."
> 
> 
>In case when AS-external LSA has non-zero FA, why do we need to look up 
> the routing table entries for ASBR, that originated the LSA? It is possible 
> that FA is available via other ASBR(s). This is valid case when there are 
> more than one ASBRs, and all may originate AS-external LSA with the same FA 
> and metric for some external destination, but only one (with highest RID) 
> will originate such LSA (RFC 2328, section 12.4.4.1). Another case with 
> Type-7 to Type-5 translation doing by ABRs in Candidate mode (RFC 3101).
> 
>Per my understanding a calculating router should initially analyse FA 
> value and only then check availability of ASBR or FA, depending on whether FA 
> is zero or not. Am I missing something?
> 
>Thanks.
>___
>Lsr mailing list
>Lsr@ietf.org
>https://www.ietf.org/mailman/listinfo/lsr
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering Tunnels" - draft-ietf-ospf-xaf-te-05

[Alexander Okonnikov]

Hi Acee,

For me current version doesn't change the solution. My comments are follow:

1.  Introduction

"TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been described to 
support intra-area TE in IPv4 and IPv6 networks, respectively.  In both cases, 
the TE database provides a tight coupling between the routed protocol and 
advertised TE signaling information.  In other words, any use of the TE link 
state database is limited to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 
[RFC5340]."

What is meant for "routed protocol"? Is it passenger protocol of RSVP-TE LSPs, 
protocol used as a transport for RSVP signaling, protocol for which 
OSPFv2/OSPFv3 calculate routes?  What does mean "TEDB is limited to IPv4/IPv6"? 
Is it limited to choose IPv4/IPv6 as a transport for RSVP-TE LSP signaling?

"For example, an LSP created based on MPLS TE information propagated by an 
OSPFv2 instance can be used to transport both IPv4 and IPv6 traffic, as opposed 
to using both OSPFv2 and OSPFv3 to provision a separate LSP for each address 
family."

An LSP created based on TEDB from OSPFv2 can be used to transport IPv4 and IPv6 
without extensions, proposed in the draft. We are not obligated to signal 
RSVP-TE LSPs from OSPFv2 TEDB for IPv4 traffic and other RSVP-TE LSPs from 
OSPFv3 TEDB for IPv6 traffic. RSVP-TE LSPs signaled based on TEDB from either - 
OSPFv2 or OSPFv3 - can be used for transport either - IPv4 or IPv6 - traffic. 
I.e. payload of RSVP-TE LSP and transport protocol for its signaling are not 
obligated to be the same. I guess that authors meant that an LSP, based on MPLS 
TE from OSPFv2, can be used for calculation of shortcuts by OSPFv2, and not by 
OSPFv3.

Authors provide description of possible solution with common Router ID. I 
propose similar solution with advertising both Router IDs (OSPFv2 and OSPFv3) 
in both instances (OSPFv2 and OSPFv3). Latter overcomes issues with correctness 
of configuration and out of sync. Also, I don't understand how can possible 
solution with common Router ID have problem with different placement of ABRs in 
OSPFv2 and OSPFv3. We are talking about intra-area LSPs, hence tail-end router 
should be within area in both instances.


3.  Operation

"A node that implements X-AF routing SHOULD advertise, in the corresponding 
Node Local Address sub-TLV, all X-AF IPv4 and IPv6 addresses local to the 
router that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs."

From section 1 we assume that X-AF is used for calculation of shortcuts. Why 
does the draft say here about calculation of TE LSPs by CSPF?

"If the Node Attribute TLV carries both the Node IPv4 Local Address sub-TLV and 
the Node IPv6 Local Address sub-TLV, then the X-AF component MUST be considered 
for the consolidated calculation of MPLS TE LSPs."

The same.


Thanks.


> 31 янв. 2019 г., в 2:03, Acee Lindem (acee)  написал(а):
> 
> Hi Gunter, Alex, Ketan, 
> I hoping everyone who commenting on the previous version is happy with the 
> version. I’m extending the WG last call another week to see if we have any 
> objections to this version.
> Thanks,
> Acee
>  
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Acee Lindem mailto:a...@cisco.com>>
> Date: Monday, January 7, 2019 at 11:47 AM
> To: "lsr@ietf.org " mailto:lsr@ietf.org>>
> Cc: "draft-ietf-ospf-xaf...@ietf.org 
> "  >
> Subject: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering 
> Tunnels" - draft-ietf-ospf-xaf-te-05
>  
> This begins an LSR WG last call for the subject draft. Please send your
> comments to this list prior to 12:00 AM GMT, January 22nd, 2019.
>  
> Note that the second IPR poll was completed in December.
>  
> Thanks,
> Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] OSPF TE Link Local TLV

[Alexander Okonnikov]

Hi Acee,

Yes, RFC 8510 provides alternative mechanism, but link identifier discovery 
mechanism via link-local TE LSA is still valid. Hence, I think that early 
mentioned issues need to be addressed.

Thank you!

> 5 февр. 2019 г., в 21:29, Acee Lindem (acee)  написал(а):
> 
> Hi Alex, 
>  
> From: Alexander Okonnikov  <mailto:alexander.okonni...@gmail.com>>
> Date: Tuesday, February 5, 2019 at 12:59 PM
> To: Acee Lindem mailto:a...@cisco.com>>, "cc...@ietf.org 
> <mailto:cc...@ietf.org>" mailto:cc...@ietf.org>>, 
> "lsr@ietf.org <mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
> Subject: Re: [Lsr] OSPF TE Link Local TLV
>  
> Hi Acee,
>  
> Per my understanding Link Local/Remote ID Sub-TLV is to be conveyed in 
> area-scope LSA to uniquely identify link between pair of routers. For 
> link-local scope another Sub-TLV was introduced, for discovery of link IDs by 
> two neighbors.
>  
> The context is completely different – see 
> https://www.rfc-editor.org/rfc/rfc8510.txt 
> <https://www.rfc-editor.org/rfc/rfc8510.txt>
>  
> May be, it is possible to reuse Link Local/Remote ID Sub-TLV (with Remote ID 
> = 0) of Link TLV in link-local scope LSA, but the RFC follows another 
> approach - to use another Sub-TLV and another TLV. I am not sure that we 
> needed dedicated top-level TLV, though idea to use separate Sub-TLV seems to 
> be reasonable.
>  
> It is also possible to use a sledge hammer to crack a nut…. 
>  
> Acee 
>  
> Thank you!
>  
> Best regards,
> Alexander Okonnikov
>  
> От: Acee Lindem (acee) mailto:a...@cisco.com>>
> Отправлено: вторник, февраля 5, 2019 20:21
> Кому: Alexander Okonnikov; cc...@ietf.org <mailto:cc...@ietf.org>; 
> lsr@ietf.org <mailto:lsr@ietf.org>
> Тема: Re: [Lsr] OSPF TE Link Local TLV 
>  
> Hi Alex, 
>  
>  
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Alexander Okonnikov  <mailto:alexander.okonni...@gmail.com>>
> Date: Tuesday, February 5, 2019 at 7:48 AM
> To: "cc...@ietf.org <mailto:cc...@ietf.org>"  <mailto:cc...@ietf.org>>, "lsr@ietf.org <mailto:lsr@ietf.org>"  <mailto:lsr@ietf.org>>
> Subject: [Lsr] OSPF TE Link Local TLV
>  
> Hi,
>  
> I have question regarding RFC 4203, Section 3. That section introduces 
> top-level TLV type 4 (Link Local TLV) and, at the same time, describes Link 
> Local Identifier TLV. I guess that latter in fact is Sub-TLV of Link Local 
> TLV. Also, IANA Considerations section doesn't mention that Sub-TLV, but only 
> introduction of Link Local TLV. IANA has no corresponding registry  - "Types 
> for Sub-TLVs of Link Local TLV (Value 4)".
>  
> I believe this example is actually wrong and section 3 should refer to the 
> top-level Link TLV (value 2) defined in RFC 3630. The Link Local Identifier 
> is the one advertised in Link Local/Remote Identifiers Sub-TLV (type 11) 
> defined in RFC 4203 section 1.1. 
>  
> Hope this helps, 
> Acee
>  
> Thanks in advance.
>  
> Best regards,
> Alexander Okonnikov

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] OSPF TE Link Local TLV

[Alexander Okonnikov]

Hi,

I have question regarding RFC 4203, Section 3. That section introduces 
top-level TLV type 4 (Link Local TLV) and, at the same time, describes Link 
Local Identifier TLV. I guess that latter in fact is Sub-TLV of Link Local TLV. 
Also, IANA Considerations section doesn't mention that Sub-TLV, but only 
introduction of Link Local TLV. IANA has no corresponding registry  - "Types 
for Sub-TLVs of Link Local TLV (Value 4)".

Thanks in advance.

Best regards,
Alexander Okonnikov

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt

[Alexander Okonnikov]

Hi Anton,

I tend to agree with Ketan, but with slightly different proposal. Would not it 
be simpler to advertise IPv6 Router Address TLV (TLV type 3) by OSPFv2 Opaque 
LSA (in addition to advertising of Router Address TLV) and to advertise Router 
Address TLV (TLV type 1) by OSPFv3 Intra-Area-TE-LSA (in addition to 
advertising IPv6 Router Address TLV)? In this case we can identify the same 
router represented by OSPFv2 and OSPFv3 and don't need the extension provided 
by the draft.

Regarding calculation of LSPs towards non-TE addresses - head-end uses non-TE 
address in order to determine TE Router ID of the tail-end (which holds that 
non-TE address); then head-end uses TE RID in CSPF calculation (though it will, 
probably, use that non-TE address as a destination in RSVP-TE signaling). 
Hence, head-end can hold mapping of destination IP of an LSP to corresponding 
TE RID of tail-end. Then, if the same head-end attempts to calculate LSP using 
TEDB from OSPFv3 (OSPFv2), it will be able to determine whether LSP already 
have been signaled using OSPFv2 (OSPFv3) TEDB.

Also, the draft several times says about using TEDB(s) for calculation of LSPs 
and, on the other hand, for using LSPs for calculation of OSPF routes. Per my 
understanding these are two different independent tasks - calculation of LSPs 
and their usage. The second task is what defined by RFC 3906, and you want to 
extend it such that SPF for one AF can utilise LSPs as shortcuts, created for 
other AF. My understanding that these two tasks need to be discussed 
separately. It could be two different documents, or two different sections of 
the same one.

Thank you.

> 25 окт. 2018 г., в 19:57, Anton Smirnov  написал(а):
> 
>Hi Ketan,
> 
> 1. I am not sure I understood the question. Your example says "using the TE 
> topology from OSPFv2 to compute a tunnel". In that case TE router ID is an 
> IPv4 address. So no, advertising IPv6 address won't help to identify the 
> tunnel.
> 2. my opinion (not discussed with other authors): RFC 3906 is Informational 
> RFC, so it is not mandatory for implementation to follow. I think we can 
> insert mention to that RFC somewhere in the Introduction but wording should 
> be sufficiently weak (like "one possible example of route computation 
> algorithm...").
> ---
> Anton
> 
> On 10/24/18 12:06, Ketan Talaulikar (ketant) wrote:
>> Hello All,
>>  
>> I support this simple but important extension.
>>  
>> A couple of minor comments on the draft:
>>  
>> 1) Sec 3 says
>>  
>>A node that implements X-AF routing SHOULD advertise, in the
>>corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6
>>addresses local to the router that can be used by Constrained SPF
>>(CSPF) to calculate MPLS TE LSPs.  In general, OSPF SHOULD advertise
>>the IP address listed in the Router Address TLV [RFC3630 
>> ] [RFC5329 
>> ]
>>of the X-AF instance maintaining the MPLS TE database, plus any
>>additional local addresses advertised by the X-AF OSPF instance in
>>its Node Local Address sub-TLVs.  An implementation MAY advertise
>>other local X-AF addresses.
>>  
>> Generally speaking, should the IP address (TE router ID in common terms) 
>> which is candidate for inclusion in the Router Address TLV not be a MUST 
>> candidate for X-AF advertisement?
>>  
>> I also have a question about the first statement with the SHOULD in it. 
>> Consider we are using the TE topology from OSPFv2 to compute a tunnel for 
>> use with OSPFv3. Any IPv6 addresses associated with the OSPFv3 instance on a 
>> router would be advertised as a Node attribute and would not help identify a 
>> specific link. So practically, if any IPv6 addresses (if at all) were to be 
>> used for CSPF then it would just identify the node – in this case, isn’t 
>> advertising the IPv6 address (TE router ID used in Router Address TLV) 
>> sufficient?
>>  
>> For practical deployment, it think it would help if this was clarified that 
>> we really need only the TE Router ID Address to go X-AF in most/general 
>> cases and not the others?
>>  
>> 2) Isn’t the mapping algorithm in Sec 3 actually going to be used for 
>> IGP short-cut use-case with its reference to the IGP cost of the tunnel? If 
>> so, would a reference to rfc3906 be helpful in this document.
>>  
>> Thanks,
>> Ketan
>>  
>> From: Lsr   On Behalf Of 
>> Acee Lindem (acee)
>> Sent: 23 October 2018 03:55
>> To: lsr@ietf.org 
>> Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering 
>> Tunnels - draft-ietf-ospf-xaf-te-04.txt
>>  
>> This begins an LSR WG last call for the subject draft. Please send your 
>> comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its 
>> only an 8 page document, I added an extra week due to the IETF. Please let 
>> me know if anyone needs any more time.
>>  
>> 

Re: [Lsr] advertising tunnels in IGP

[Alexander Okonnikov]

Hi,

I think that problem here is that two LSPs are two independent unidirectional 
links, rather than one bidirectional. Moreover, LSPs in two directions are not 
pairs (some two LSPs are not associated to each other), and amount of LSPs in 
each direction is not necessary the same. I could assume that some router uses 
Interface IDs for two-way check, but it is not so straightforward when we have 
deal with FAs.

Acee, two-way check could be disabled on the router that is owner of FA, but 
how other routers will distinguish regular P2P from FA?
Thank you.

Best regards,
Alexander Okonnikov

1 марта 2018 г., 19:37 +0300, Acee Lindem (acee) <a...@cisco.com>, писал:
> Hi Dirk,
>
> My memory has faded somewhat on Forwarding Adjacency (FA) implementation. 
> However, since basic MPLS LSPs are unidirectional, doesn’t the SPF two-way 
> check have to be disabled anyway? If so, the Remote Interface ID doesn’t 
> matter.
>
> Thanks,
> Acee
>
> From: Lsr <lsr-boun...@ietf.org> on behalf of "Goethals, Dirk (Nokia - 
> BE/Antwerp)" <dirk.goeth...@nokia.com>
> Date: Thursday, March 1, 2018 at 11:06 AM
> To: "lsr@ietf.org" <lsr@ietf.org>
> Subject: [Lsr] advertising tunnels in IGP
>
> Hi,
> In OSPFv2 (and ISIS), we can add (RSVP) tunnels to the topology
> by adding them as a unnumbered link in the router lsa.
> In OSPFv3, we can only add a link to the router-lsa if the neighbor
> interface ID is known.
> So it looks like we can only add a tunnel to the OSPFv3 topology,
> if we first exchanging hello packets over the tunnel.
> Is that correct?
> As this is not needed in the other IGPs, do
> we have other possibilities?
> Thx,
> Dirk
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr