Hi Warren,

From: Warren Kumari <[email protected]>
Date: Friday, May 15, 2020 at 1:25 PM
To: "Peter Psenak (ppsenak)" <[email protected]>
Cc: The IESG <[email protected]>, "[email protected]" 
<[email protected]>, "[email protected]" 
<[email protected]>, "[email protected]" <[email protected]>, Acee Lindem 
<[email protected]>, Alvaro Retana <[email protected]>
Subject: Re: Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with 
COMMENT)
Resent-From: <[email protected]>
Resent-To: Acee Lindem <[email protected]>, Yingzhen Qu <[email protected]>, 
Christian Hopps <[email protected]>
Resent-Date: Friday, May 15, 2020 at 1:25 PM



On Fri, May 15, 2020 at 7:28 AM Peter Psenak 
<[email protected]<mailto:[email protected]>> wrote:
Hi Warren,

On 15/05/2020 03:25, Warren Kumari via Datatracker wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-ospf-mpls-elc-13: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Nit: “ When an OSPF Autonomous System Boundary Router (ASBR) redistributes a
> prefix from another instance of the OSPF or from some other protocol,   it
> SHOULD preserve the ELC signaling for the prefix.“
>
> S/the /OSPF/OSPF/.

fixed.

thanks!

>
> S/for the prefix/for the prefix (if it exists)/ — some protocols will not have
> / carry the ELC.

fixed.

thanks!

>
> Apologies if I missed it, but I didn’t see discussion on *exporting* ELC into
> other protocols...

what do you mean by "exporting"?

Sorry -- the above discusses : "When an OSPF Autonomous System Boundary Router 
(ASBR) redistributes a prefix ... FROM some other protocol,  " (imports), but 
presumably you would also like to be able to do "When an OSPF Autonomous System 
Boundary Router (ASBR) redistributes a prefix **INTO** some other protocol,  
..." (exports). Yes, the "other protocol" document should describe this in 
detail, but I think that it is worth mentioning the topic here -- we may be 
helpful for implementers to keep in mind that this may occur, and so the data 
should be reachable (likely through the RIB).

Can you suggest some text? Do you realize that in the Routing Area, route 
redistribution (aka, route import/export) has always been considered an 
implementation matter and is not formally specified. It would hard to 
standardize this now (other than Routing Policy YANG model) due to differences 
between implementations.

Thanks,
Acee

W


thanks,
Peter

>
>
>
>
>


--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to