Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Peter Psenak <[e-mail]>]

Elwyn,

On 18/05/2020 23:02, elwynd wrote:
> Hi.
> 
> I am not convinced by the discussion that has ensued from my review.
> 
> s3, para 3:
> 
>     If the router supports ELs on all of its interfaces, it SHOULD
>     advertise the ELC with every local host prefix it advertises in OSPF.
> 
> - Both Acee amd I didn't immediately understand that 'every local host prefix' was not every
>    prefix that the router might advertise.  It would be good to explain that this is the case.

what exactly needs to be explained? The local property of the prefix?

> 
> - As I previously stated, with a SHOULD it ought to be explained why one might not want to
>    advertise the ELC with some subset of the local host prefixes.

SHOUDL is used not to say that one does it for subset of host prefixes, 
but rather because MUST can not be used for reasons mentioned earlier.

 From the functionality perspective it is sufficient to advertise it 
with a single local prefix. We specified for "every local prefix" to 
make it simpler.

> 
> - Given that there are now two sets of prefixes, would/SHOULD/MUST ELC be advertised with the
>    prefixes that are not local host prefixes?

no, only with local host prefixes. I can add  "MUST NOT be advertised 
with any other prefix" if that's what you are after.


> 
> s4, para 3:
> 
>     The absence of ERLD-MSD advertisements indicates only that the
>     advertising node does not support advertisement of this capability.
> 
> Firstly, I cannot see why this statement or its absence might affect other EL mechanisms that
> don't use OSPF to do signaling of ELC.

It does not. All we say that if it is not advertised by OSPF, it means 
the router does not support the advertisement in OSPF. Nothing else. It 
has no effect on any other mechanisms that might be used to derive these 
capabilities.

> 
> If I understand RFC 8662 correctly, if OSPF is being used to distribute ELC adverts and the ERLD
> is not advertised by OSPF, then either the ERLD has to be supplied by other means or it will
> effectively default to zero.
> 
> Thus, I would suggest that the paragraph above should be replaced with:
> 
>     Advertisement of ERLD via OSPF using ERLD-MSD is OPTIONAL.  If a router does not advertise
>     ERLD, then the EL positioning calculations described in [RFC8662] will assume a vaue of zero
>     for the ERLD of this router unless a different value is supplied by alternative means.

I don't think we should be specifying anything that belongs to RFC8662 
here in this draft. What we specify in this draft is how to advertise 
something in OSPF, not how this is being used, because this information 
is not used by OSPF. The usage of this info is outside of the scope of 
this draft and if anything needs to be added in that regard it should be 
done by updating the RFC8662.

regards,
Peter



> 
> Regards,
> 
> Elwyn
> 
> Sent from Samsung tablet.
> 
> 
> 
> -------- Original message --------
> From: "Acee Lindem (acee)" <[e-mail]>
> Date: 14/05/2020 21:43 (GMT+00:00)
> To: Alvaro Retana <[e-mail]>, "Peter Psenak (ppsenak)" 
> <[e-mail]>, Elwyn Davies <[e-mail]>, [e-mail]
> Cc: [e-mail], [e-mail], [e-mail]
> Subject: Re: Genart last call review of draft-ietf-ospf-mpls-elc-13
> 
> Hi Alvaro, Elwyn,
> 
> *From: *Alvaro Retana <[e-mail]>
> *Date: *Thursday, May 14, 2020 at 3:46 PM
> *To: *Acee Lindem <[e-mail]>, "Peter Psenak (ppsenak)" 
> <[e-mail]>, Elwyn Davies <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, 
> "[e-mail]" 
> <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: Genart last call review of draft-ietf-ospf-mpls-elc-13
> 
> Hi!
> 
> Yes, we cannot specify something that routers unaware of this 
> specification should or shouldn’t do.
> 
> I believe that Elwyn’s point is this: *if a router supports this 
> specification* then when would it not advertise the ELC?  IOW, the 
> specification only obviously applies to implementations that support it 
> — in that case I would think that if a router supports ELs on all of its 
> interfaces then it would always advertise the ELC, right?
> 
> That’s true – but not advertising the OSPF capability could imply that 
> either ELC MSD or advertisement of the OSPF capability is not supported. 
> Although I might not have worded it as such, that was clear to me from 
> the text. Feel free to recommend alternate text if you feel it is 
> necessary.
> 
> Thanks,
> 
> Acee
> 
> Thanks!
> 
> Alvaro.
> 
> On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) ([e-mail] 
> <mailto:[e-mail]>) wrote:
> 
>     Note that the optionality of ERLD-MSD advertisements appears on
>     reflection to be a more serious issue than just an editorial nit.
> 
>     So what would you suggest? There are existing implementations that
>     support multipath forwarding entropy using MPLS entropy labels but
>     do not signal that capability in OSPF. We can't have a document that
>     retroactively mandates that they signal it. This wouldn't be
>     backward compatible. How can you possibly see this as a serious issue?
>