Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

2020-05-15 Thread Warren Kumari 
On Fri, May 15, 2020 at 8:07 PM Les Ginsberg (ginsberg) 
wrote:

> Warren –
>
>
>
> The problem I have with your suggestion is that we do not know whether the
> destination protocol for redistribution even supports the signaling.
>
>
>
> I am very supportive of Acee’s characterization of redistribution as
> outside the scope of specification.
>
>
Okey dokey, I’m convinced...

Thanks, w


>
> I think we can say what happens intra-protocol – but we should stay away
> from inter-protocol statements.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Warren Kumari
> *Sent:* Friday, May 15, 2020 2:08 PM
> *To:* Acee Lindem (acee) 
> *Cc:* draft-ietf-ospf-mpls-...@ietf.org; Alvaro Retana <
> aretana.i...@gmail.com>; lsr-cha...@ietf.org; The IESG ;
> lsr@ietf.org; Peter Psenak (ppsenak) 
> *Subject:* Re: [Lsr] Warren Kumari's No Objection on
> draft-ietf-ospf-mpls-elc-13: (with COMMENT)
>
>
>
>
>
>
>
> On Fri, May 15, 2020 at 1:34 PM Acee Lindem (acee)  wrote:
>
> Hi Warren,
>
>
>
> *From: *Warren Kumari 
> *Date: *Friday, May 15, 2020 at 1:25 PM
> *To: *"Peter Psenak (ppsenak)" 
> *Cc: *The IESG , "draft-ietf-ospf-mpls-...@ietf.org" <
> draft-ietf-ospf-mpls-...@ietf.org>, "lsr-cha...@ietf.org" <
> lsr-cha...@ietf.org>, "lsr@ietf.org" , Acee Lindem <
> a...@cisco.com>, Alvaro Retana 
> *Subject: *Re: Warren Kumari's No Objection on
> draft-ietf-ospf-mpls-elc-13: (with COMMENT)
> *Resent-From: *
> *Resent-To: *Acee Lindem , Yingzhen Qu <
> yingzhen.i...@gmail.com>, Christian Hopps 
> *Resent-Date: *Friday, May 15, 2020 at 1:25 PM
>
>
>
>
>
>
>
> On Fri, May 15, 2020 at 7:28 AM Peter Psenak  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.
>
>
>
> Sure -- how about something like:
>
>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.
>
>   **In addition ASBRs should allow the
>
>   ELC signaling for the prefix to be preserved when redistributing
> to another instance of OSPF or to some other protocol**
>
>
>
> (Addition in asterisks).
>
> Note that this is just a suggestion / not a hill I care to die on -- as an
> ops person, when I read "you should be able to preserve X when importing
> into Y", I automatically start wondering how / if I can preserve X when
> exporting from Y.
>
>
>
> But, 'm also fine if y'all don't want to address this,
>
> W
>
>
>
>
>
>
>
> 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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

2020-05-15 Thread Huaimo Chen 
Hi Acee,

Yes. I am aware of IPRs that apply to this draft, which have been disclosed 
in compliance with IETF IPR rules.

Best Regards,
Huaimo

From: Acee Lindem (acee) 
Sent: Friday, May 15, 2020 3:47 PM
To: draft-cc-lsr-flooding-reduct...@ietf.org 

Cc: lsr@ietf.org 
Subject: Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 IPR Poll


Authors,



Are you aware of any IPR that applies to 
draft-cc-lsr-flooding-reduction-08..txt.



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.



Thanks,

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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-15 Thread Huaimo Chen 
Support.

Best Regards,
Huaimo as co-author

From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Friday, May 15, 2020 3:39 PM
To: lsr@ietf.org 
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/



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

Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

2020-05-15 Thread Les Ginsberg (ginsberg) 
Warren –

The problem I have with your suggestion is that we do not know whether the 
destination protocol for redistribution even supports the signaling.

I am very supportive of Acee’s characterization of redistribution as outside 
the scope of specification.

I think we can say what happens intra-protocol – but we should stay away from 
inter-protocol statements.

   Les


From: Lsr  On Behalf Of Warren Kumari
Sent: Friday, May 15, 2020 2:08 PM
To: Acee Lindem (acee) 
Cc: draft-ietf-ospf-mpls-...@ietf.org; Alvaro Retana ; 
lsr-cha...@ietf.org; The IESG ; lsr@ietf.org; Peter Psenak 
(ppsenak) 
Subject: Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: 
(with COMMENT)



On Fri, May 15, 2020 at 1:34 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Warren,

From: Warren Kumari mailto:war...@kumari.net>>
Date: Friday, May 15, 2020 at 1:25 PM
To: "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>
Cc: The IESG mailto:i...@ietf.org>>, 
"draft-ietf-ospf-mpls-...@ietf.org" 
mailto:draft-ietf-ospf-mpls-...@ietf.org>>, 
"lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>, Acee 
Lindem mailto:a...@cisco.com>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: Re: Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with 
COMMENT)
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Friday, May 15, 2020 at 1:25 PM



On Fri, May 15, 2020 at 7:28 AM Peter Psenak 
mailto:ppse...@cisco.com>> 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.

Sure -- how about something like:
   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.
  **In addition ASBRs should allow the
  ELC signaling for the prefix to be preserved when redistributing to another 
instance of OSPF or to some other protocol**

(Addition in asterisks).
Note that this is just a suggestion / not a hill I care to die on -- as an ops 
person, when I read "you should be able to preserve X when importing into Y", I 
automatically start wondering how / if I can preserve X when exporting from Y.

But, 'm also fine if y'all don't want to address this,
W



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


--
I

Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

2020-05-15 Thread Warren Kumari 
On Fri, May 15, 2020 at 1:34 PM Acee Lindem (acee)  wrote:

> Hi Warren,
>
>
>
> *From: *Warren Kumari 
> *Date: *Friday, May 15, 2020 at 1:25 PM
> *To: *"Peter Psenak (ppsenak)" 
> *Cc: *The IESG , "draft-ietf-ospf-mpls-...@ietf.org" <
> draft-ietf-ospf-mpls-...@ietf.org>, "lsr-cha...@ietf.org" <
> lsr-cha...@ietf.org>, "lsr@ietf.org" , Acee Lindem <
> a...@cisco.com>, Alvaro Retana 
> *Subject: *Re: Warren Kumari's No Objection on
> draft-ietf-ospf-mpls-elc-13: (with COMMENT)
> *Resent-From: *
> *Resent-To: *Acee Lindem , Yingzhen Qu <
> yingzhen.i...@gmail.com>, Christian Hopps 
> *Resent-Date: *Friday, May 15, 2020 at 1:25 PM
>
>
>
>
>
>
>
> On Fri, May 15, 2020 at 7:28 AM Peter Psenak  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.
>

Sure -- how about something like:
   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.
  **In addition ASBRs should allow the
  ELC signaling for the prefix to be preserved when redistributing
to another instance of OSPF or to some other protocol**

(Addition in asterisks).
Note that this is just a suggestion / not a hill I care to die on -- as an
ops person, when I read "you should be able to preserve X when importing
into Y", I automatically start wondering how / if I can preserve X when
exporting from Y.

But, 'm also fine if y'all don't want to address this,
W



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


-- 
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

2020-05-15 Thread Acee Lindem (acee) 
Authors,

Are you aware of any IPR that applies to draft-cc-lsr-flooding-reduction-08.txt.

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

[Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-15 Thread Acee Lindem (acee) 
This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

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

Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

2020-05-15 Thread Acee Lindem (acee) 
Hi Warren,

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



On Fri, May 15, 2020 at 7:28 AM Peter Psenak 
mailto:ppse...@cisco.com>> 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

2020-05-15 Thread Warren Kumari 
On Fri, May 15, 2020 at 7:28 AM Peter Psenak  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).

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

2020-05-15 Thread Peter Psenak 

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.



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


fixed.



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


what do you mean by "exporting"?

thanks,
Peter









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

Re: [Lsr] OSPFv3 Implementations of draft-ietf-ospf-mpls-elc

2020-05-15 Thread Peter Psenak 

Hi,

I'm going to update the draft to use bit 0x40 in "OSPFv3 Prefix Options 
(8 bits) registry" for E-Flag (ELC Flag).


thanks,
Peter

On 07/05/2020 15:10, Alvaro Retana wrote:

Dear lsr WG:

If you’ve been following the progress of this document, you will have 
noticed that it is already in IESG Evaluation.


IANA discovered a typo in the draft; the current text says "Bit 0x04 in 
the "OSPFv3 Prefix Options (8 bits) registry has been assigned to the 
E-Flag (ELC Flag)”.   However, the value assigned by IANA is 0x40.



Does anyone have an OSPFv3 implementation of this document?  If so, 
which value is used, 0x04 or 0x40?  Are there deployments?



The Shepherd report doesn’t mention any implementations, and with the 
help of the authors it has already been confirmed that cisco, Nokia and 
Huawei don’t have an OSPFv3 implementation.



Please respond by COB on May 14.


Thanks!

Alvaro.


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

Re: [Lsr] AD Review of draft-ietf-ospf-te-link-attr-reuse-10

2020-05-15 Thread Peter Psenak 

Hi Alvaro,

please see inline (##PP)

On 14/05/2020 19:26, Alvaro Retana wrote:

On May 5, 2020 at 6:08:27 AM, Peter Psenak wrote:


Peter:

Hi!


...

I tried to address all of them, some have been resolved during ISIS
draft review, in which case I took the same resolution for this draf.

Please see inline, look for ##PP



There's only one outstanding comment that I don't think was answered
-- or at least I missed the meaning of the answer.  Please see below.


I am also including some comments based on -11.  Except for the
Normative language in §12.1, all the comments are basically
nits/suggestions.


I am starting the IETF Last Call for this document and
draft-ietf-isis-te-app.  We can work on these remaining comments while
we do that.

Thanks!

Alvaro.



...

434 6. Local Interface IPv6 Address Sub-TLV

[major] The Local/Remote Interface IPv6 Address Sub-TLVs (rfc5329) can
include multiple addresses for a link. It seems to me that it could
be possible for different applications to use different addresses. If
that is the case, then it seems that these sub-TLVs should not be
application independent. Why are they not considered to be
application specific?

[minor] Why are IPv4 addresses not considered?

##PP
IPv4 local address is part of the basic spec.
IPv6 remote address has been added in rfc8379.


For IPv4: what basic spec?

For IPv6: rfc8379 doesn’t seem to relate to the questions — am I
missing something?


##PP
interface's IP address is part of the Router-LSA's link data - RFC2328, 
section A.4.2.








[Line numbers from idnits]

draft-ietf-ospf-te-link-attr-reuse-11

...
168 4.1.  OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA
...
184    3.  There is clear distinction between link attributes used by RSVP-
185        TE and link attributes used by other OSPFv2 or OSPFv3
186        applications.

[nit] s/is clear distinction/is a clear distinction


##PP
fixed



...
203    TE link attributes used for RSVP-TE/GMPLS continue use OSPFv2 TE
204    Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].

[nit] s/continue use/continue to use


##PP
fixed



...
213 5.  Advertisement of Application Specific Values
...
252       SABM Length: Standard Application Identifier Bit-Mask Length in
253       octets.  The legal values are 0, 4 or 8.  If the Standard
254       Application Bit-Mask is not present, the Standard Application Bit-
255       Mask Length MUST be set to 0.

257       UDABM Length: User Defined Application Identifier Bit-Mask Length
258       in octets.  The legal values are 0, 4 or 8.  If the User Defined
259       Application Bit-Mask is not present, the User Defined Application
260       Bit-Mask Length MUST be set to 0.

[minor] "The legal values are 0, 4 or 8."  Should the statement be
Normative ("MUST be...")?  I know there is a sentence below about
ignoring the sub-TLV if a different value is received -- IOW, just a
suggestion.


##PP
Changed to MUST be




...
319       - Unidirectional Link Dela [RFC7471]

321       - Min/Max Unidirectional Link Delay [RFC7471]
322       - Unidirectional Delay Variation [RFC7471]

[nit] There seems to be a line missing...


##PP
sorry, what line is missing? There is a page break there.





...
532 12.1.  Use of Legacy RSVP-TE LSA Advertisements

534    Bit Identifiers for Standard Applications are defined in Section 5.
535    All of the identifiers defined in this document are associated with
536    applications which were already deployed in some networks prior to
537    the writing of this document.  Therefore, such applications have been
538    deployed using the RSVP-TE LSA advertisements.  The Standard
539    Applications defined in this document MAY continue to use RSVP-TE LSA
540    advertisements for a given link so long as at least one of the
541    following conditions is true:

[major] s/MAY/may


##PP
ok, changed to may




...
651 12.3.4.  Use of Application Specific Advertisements for RSVP-TE

653    The extensions defined in this document support RSVP-TE as one of the
654    supported applications.  It is however RECOMMENDED to advertise all
655    link-attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA
656    [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329] to maintain backward
657    compatibility.  RSVP-TE can eventually utilize the application
658    specific advertisements for newly defined link attributes, which are
659    defined as application specific.

[minor] "It is however RECOMMENDED to advertise all link-attributes
for RSVP-TE in the existing..."  The application specific
advertisements can be used and result in duplicate information.  The
ISIS draft includes some sample steps to eliminate redundancy and get
rid of the legacy advertisements -- can we add something similar here?


##PP
not really. We do NOT want to do what ISIS does in OSPF. ISIS has a