Re: [Lsr] IPR Poll for "IGP extension for PCEP security capability support in the PCE discovery" (Corrected)

[Qin Wu]

It seems there was one relevant IPR
https://patents.google.com/patent/US8127129B2/en
but I am not sure it is applicable. I will consult with our IPR people to check 
on this.

-Qin
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2018年11月16日 11:59
收件人: draft-wu-lsr-pce-discovery-security-support
抄送: lsr@ietf.org; p...@ietf.org
主题: Re: [Lsr] IPR Poll for "IGP extension for PCEP security capability support 
in the PCE discovery" (Corrected)

Authors – Reminder that you need to explicitly reply to this poll.

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee 
Lindem mailto:a...@cisco.com>>
Date: Wednesday, November 14, 2018 at 3:02 PM
To: draft-wu-lsr-pce-discovery-security-support 
mailto:draft-wu-lsr-pce-discovery-security-supp...@ietf.org>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [Lsr] IPR Poll for "IGP extension for PCEP security capability support 
in the PCE discovery" (Corrected)

Authors,

Are you aware of any IPR that applies to 
draft-wu-lsr-pce-discovery-security-support?

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

There are currently no IPR disclosures against 
draft-wu-lsr-pce-discovery-security-support.

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] LSR: Using DSCP for path/topology selection Q

[Robert Raszuk]

Jeff,

> What architecture?
> PBR is a form of:
> match DSCP X
> set next-hop Y
> needs no interoperability...

That's pretty narrow view. I could say the worst possible example :)  You
would have to either encapsulate or apply your sample config consistently
on every hop. Br.

To me DSCP can be used to map packets to different routing context,
different plane or can be used as a parameter in flex-algorithm.

Thx,
R.





On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura 
wrote:

> Tony,
>
> What architecture?
> PBR is a form of:
> match DSCP X
> set next-hop Y
> needs no interoperability...
> If someone wants to describe how they use a particular vendor feature to
> solve a particular problem in a BCP, sure, the more BCPs - the better.
>
> Wrt using DSCP in routing decision process - it was a bad idea back then,
> hasn’t got any better now... besides - now we have got a toolbox that
> wasn’t available then.
>
> Cheers,
> Jeff
> On Thu, Nov 15, 2018 at 22:56 Tony Li  wrote:
>
>>
>>
>> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura 
>> wrote:
>>
>> The question is really - what is here to standardize?
>>
>>
>>
>> There’s a fine architectural BCP here: this is how we are solving problem
>> XYZ.  Please don’t break this.
>>
>> Tony
>>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Tony Li]

> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura  wrote:
> 
> The question is really - what is here to standardize?


There’s a fine architectural BCP here: this is how we are solving problem XYZ.  
Please don’t break this.

Tony

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

Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[Qin Wu]

Working on this. Try to figure out how to carry key name in PCED sub-TLV. It 
looks RFC5088 and RFC5089 doesn't allow add additional sub-TLVs.
"
RFC5088
No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in OSPF, this will not be carried in the Router
   Information LSA.

RFC5089
No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in IS-IS, this will not be carried in the CAPABILITY TLV.
"
The reason behind was clarified here:
https://mailarchive.ietf.org/arch/msg/pce/cR7e1SZ_DyUyY14OkfWbCc94paU
I am wondering whether there is any other key information exchange that might 
be happening during discovery mechanism.
Depending on the answer, we have three options:
1) Update RFC5088 and RFC 5089 to allow additional sub-TLVs to be added to the 
PCEP TLV.
2) carry key name using GENINFO TLV of RFC 6823
3) Carry key name during PCEP session establishment phase instead of discovery 
phase.

-Qin
-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2018年11月15日 23:18
收件人: julien.meu...@orange.com; lsr@ietf.org
抄送: p...@ietf.org
主题: Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability 
support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

Authors, 
Please note that you need not wait until the end of the adoption poll to 
address my comment and Julien's comments. 
Thanks,
Acee 

On 11/15/18, 10:02 AM, "Lsr on behalf of julien.meu...@orange.com" 
 wrote:

Hi,

Contributor hat on, I take the opportunity mentioned by Acee to
highlight some of the issues in the current version:
- The I-D teaches multiple time about RFC 5088 and 5089 (while 8253 is
only mentioned in the introduction): the discussed mechanism has been
used multiple times, there is no need to elaborate so much (see section
3.1.1 of RFC 8306 for example);
- Section 3 includes the PCE-CAP-FLAGS sub-TLV definition: having a
given specification in multiples places brings no value but may create
discrepancies, please stick to the references to the aforementioned RFCs;
- Section 3 tries to list the existing flag allocations: these are
inaccurate (e.g. RFC 6006 has been obsoleted by RFC 8306), incomplete
(e.g. RFC 8231 is missing) and inappropriate (this is the role of the
IANA registry, not of every new I-D!);
- Contrary to the written text, the I-D does not "extend" anything, it
requests bit allocation from an existing registry; the IANA section (7)
is thus key: please make it point to the relevant registry, namely "PCE
Capability Flags" managed within the "OSPFv2 Parameters"

(https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14).

Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
> Note the authors may refresh the draft to address some comments prior
> to that time. 



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Jeff Tantsura]

+1 Rob
I have seen number of MBH networks using DSCP to change forwarding - AKA PBR..

The question is really - what is here to standardize?

RSVP-TE use cases mentioned by Rob (CBTS/PBTS in IOS realm) are classical 
examples of Policy Based Routing and as such are subject to implementation 
details, not standardization.

Am I missing something?


Regards,
Jeff

> On Nov 16, 2018, at 07:47, Rob Shakir  wrote:
> 
>> On Thu, 15 Nov 2018 at 16:07 Toerless Eckert  wrote:
>> > And btw I read Peter's note as possibility (or invitation) to define
>> > algorithm which takes into account DSCP rather then a announcement that
>> > this is not there and it should never be.
>> 
>> Sure, i am only talking about the solutions that tried to use DSCP for
>> routing so far. I think those failed. And when other agree and we codify
>> that, then that would not exclude the option for new work (like what
>> Peter may have in mind) to superceed that recommendation. 
> 
> A number of networks on which I have worked have used DSCP-based tunnel 
> selection to choose between RSVP-TE LSPs. This essentially is different 
> routing based on DSCP, which seems to be something that you're trying to 
> cover -- is that correct?
> 
> If so, given that these are running in real networks, I find it hard to 
> conclude that any IETF standard should declare them as failed.
> 
> r.
> 
> 
> ___
> 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] IPR Poll for "IGP extension for PCEP security capability support in the PCE discovery" (Corrected)

[Acee Lindem (acee)]

Authors – Reminder that you need to explicitly reply to this poll.

From: Lsr  on behalf of Acee Lindem 
Date: Wednesday, November 14, 2018 at 3:02 PM
To: draft-wu-lsr-pce-discovery-security-support 

Cc: "lsr@ietf.org" 
Subject: [Lsr] IPR Poll for "IGP extension for PCEP security capability support 
in the PCE discovery" (Corrected)

Authors,

Are you aware of any IPR that applies to 
draft-wu-lsr-pce-discovery-security-support?

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

There are currently no IPR disclosures against 
draft-wu-lsr-pce-discovery-security-support.

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] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[Qin Wu]

-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 julien.meu...@orange.com
发送时间: 2018年11月15日 23:01
收件人: lsr@ietf.org
主题: Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability 
support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

Hi,

Contributor hat on, I take the opportunity mentioned by Acee to highlight some 
of the issues in the current version:
- The I-D teaches multiple time about RFC 5088 and 5089 (while 8253 is only 
mentioned in the introduction): the discussed mechanism has been used multiple 
times, there is no need to elaborate so much (see section
3.1.1 of RFC 8306 for example);
[Qin]:Good point and will following RFC8306 example to make it concise.

- Section 3 includes the PCE-CAP-FLAGS sub-TLV definition: having a given 
specification in multiples places brings no value but may create discrepancies, 
please stick to the references to the aforementioned RFCs;
[Qin]: Okay.
- Section 3 tries to list the existing flag allocations: these are inaccurate 
(e.g. RFC 6006 has been obsoleted by RFC 8306), incomplete (e.g. RFC 8231 is 
missing) and inappropriate (this is the role of the IANA registry, not of every 
new I-D!);
[Qin]:Okay, I propose to remove these.
- Contrary to the written text, the I-D does not "extend" anything, it requests 
bit allocation from an existing registry; the IANA section (7) is thus key: 
please make it point to the relevant registry, namely "PCE Capability Flags" 
managed within the "OSPFv2 Parameters"
(https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14).
[Qin]: Okay, fixed in the local copy.
Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
> Note the authors may refresh the draft to address some comments prior 
> to that time.


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
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] LSR: Using DSCP for path/topology selection Q

[Rob Shakir]

On Thu, 15 Nov 2018 at 16:07 Toerless Eckert  wrote:

> > And btw I read Peter's note as possibility (or invitation) to define
> > algorithm which takes into account DSCP rather then a announcement that
> > this is not there and it should never be.
>
> Sure, i am only talking about the solutions that tried to use DSCP for
> routing so far. I think those failed. And when other agree and we codify
> that, then that would not exclude the option for new work (like what
> Peter may have in mind) to superceed that recommendation.
>

A number of networks on which I have worked have used DSCP-based tunnel
selection to choose between RSVP-TE LSPs. This essentially is different
routing based on DSCP, which seems to be something that you're trying to
cover -- is that correct?

If so, given that these are running in real networks, I find it hard to
conclude that any IETF standard should declare them as failed.

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

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Toerless Eckert]

On Fri, Nov 16, 2018 at 12:28:27AM +0100, Robert Raszuk wrote:
> Hey Toerless,
> 
> Please observe that DSCP based steering may be very useful vehicle for end
> hosts/applications influencing how their packets are transported.
> 
> So instead of closing that option I recommend we at least take a good look
> at what alternative mechanism exists.

I think back when DSCP was selected for MTR in implementations, it was
done so due to the absence of better options. But as i mentioned, the
overloading of DSCP between QoS and routing made it (in my memory)
undesirable to operators. And when designing new solutions with new QoS
like in DetNet its yet a similar possible problem.

If we hopefully do not need to find solutions for IPv4, i would rather
like to see something like what SR did, e.g.: IPv6 header extension. These
are AFAIK now also easily settable from linux programs (ok., maybe not
yet from javascript). Or much easier of course the existing IPv6
multi-addressing solutions where hosts can also lern semntics of these
addresses. And map to diffeent flex-topologies instead of just
multi-homing exit points (which i think was the main use-case so far).

> And btw I read Peter's note as possibility (or invitation) to define
> algorithm which takes into account DSCP rather then a announcement that
> this is not there and it should never be.

Sure, i am only talking about the solutions that tried to use DSCP for
routing so far. I think those failed. And when other agree and we codify
that, then that would not exclude the option for new work (like what
Peter may have in mind) to superceed that recommendation. 

Cheers
Toerless

> Cheers,
> R.
> 
> 
> 
> On Fri, Nov 16, 2018 at 12:22 AM Toerless Eckert  wrote:
> 
> >
> > Thanks, Les, Peter
> >
> > So... is there any opinion about creating a normative or BCP
> > recommendation to
> > not use DSCP to distinguish topologies/flex-algos ? Mabybe this would
> > not be appropriate for LSR, but TSVWG, but i think it would be
> > participants in LSR that would know if there is actually still any
> > customer demand for this option.
> >
> > Cheers
> > Toerless
> >
> > P.S.: Context of the email is DetNet trying to define what a DetNet flow
> > is and currently this includes the thinking that DetNet flows could be
> > 6-tuple flows including DSCP because different DSCP could be routed
> > differently in the network via MTR, and that concept IMHO would just
> > result in making a foal (DetNet) a lot more complex because of a dead
> > horse (DSCP MTR).
> >
> > On Thu, Nov 15, 2018 at 04:41:06AM +, Les Ginsberg (ginsberg) wrote:
> > > Toerless -
> > >
> > > It's pretty hard to understand the context for your email.
> > >
> > > What leads you to believe that any of the MT specifications you mention
> > say anything normative about DSCP and topologies??
> > >
> > > RFC4915 does not mention DSCP at all - but does make the statement:
> > >
> > > https://tools.ietf.org/html/rfc4915#section-3.8
> > > "It is outside of the scope of this document to specify how the
> > >information in various topology specific forwarding structures are
> > >used during packet forwarding or how incoming packets are associated
> > >with the corresponding topology."
> > >
> > > RFC 5120 does mention DSCP, but only as an example of something that
> > "could" be used to determine on what topology a packet should be forwarded.
> > >
> > > RFC 7722 also mentions DSCP as an example, but there is a statement in
> > Section 3:
> > >
> > > "It is assumed, but
> > >outside the scope of this specification, that the network layer is
> > >able to choose which topology to use for each packet"
> > >
> > > IGP WGs have never attempted to recommend (let alone normatively define)
> > any relationship between DSCP and MT.
> > >
> > > ???
> > >
> > >Les
> > >
> > > > -Original Message-
> > > > From: Lsr  On Behalf Of Toerless Eckert
> > > > Sent: Wednesday, November 14, 2018 6:29 PM
> > > > To: lsr@ietf.org
> > > > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q
> > > >
> > > > Whats the current best guidance on using DSCP for selection of path,
> > > > specifically for selection of topology with MTR (RFCs 4915, 5120,
> > 7722) ?
> > > >
> > > > My understanding from history is that this looked like a good idea
> > > > to customers first, but when implementations became available,
> > > > customers really did not want to implement it because of the
> > overloading
> > > > of DSCP between QoS and routing and the resulting management
> > > > complexity.
> > > >
> > > > Has the idea of using DSCP for path selection been re-introduced in any
> > > > later work like flex-Algos ?
> > > >
> > > > If there could be rough consensus that this is in general a bad idea,
> > i wonder
> > > > if it would be appropriate to have a short normative document from LSR
> > > > defining that the use of DSCP for topology selection is historic and
> > > > not recommended anymore and make 

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Robert Raszuk]

Hey Toerless,

Please observe that DSCP based steering may be very useful vehicle for end
hosts/applications influencing how their packets are transported.

So instead of closing that option I recommend we at least take a good look
at what alternative mechanism exists.

And btw I read Peter's note as possibility (or invitation) to define
algorithm which takes into account DSCP rather then a announcement that
this is not there and it should never be.

Cheers,
R.



On Fri, Nov 16, 2018 at 12:22 AM Toerless Eckert  wrote:

>
> Thanks, Les, Peter
>
> So... is there any opinion about creating a normative or BCP
> recommendation to
> not use DSCP to distinguish topologies/flex-algos ? Mabybe this would
> not be appropriate for LSR, but TSVWG, but i think it would be
> participants in LSR that would know if there is actually still any
> customer demand for this option.
>
> Cheers
> Toerless
>
> P.S.: Context of the email is DetNet trying to define what a DetNet flow
> is and currently this includes the thinking that DetNet flows could be
> 6-tuple flows including DSCP because different DSCP could be routed
> differently in the network via MTR, and that concept IMHO would just
> result in making a foal (DetNet) a lot more complex because of a dead
> horse (DSCP MTR).
>
> On Thu, Nov 15, 2018 at 04:41:06AM +, Les Ginsberg (ginsberg) wrote:
> > Toerless -
> >
> > It's pretty hard to understand the context for your email.
> >
> > What leads you to believe that any of the MT specifications you mention
> say anything normative about DSCP and topologies??
> >
> > RFC4915 does not mention DSCP at all - but does make the statement:
> >
> > https://tools.ietf.org/html/rfc4915#section-3.8
> > "It is outside of the scope of this document to specify how the
> >information in various topology specific forwarding structures are
> >used during packet forwarding or how incoming packets are associated
> >with the corresponding topology."
> >
> > RFC 5120 does mention DSCP, but only as an example of something that
> "could" be used to determine on what topology a packet should be forwarded.
> >
> > RFC 7722 also mentions DSCP as an example, but there is a statement in
> Section 3:
> >
> > "It is assumed, but
> >outside the scope of this specification, that the network layer is
> >able to choose which topology to use for each packet"
> >
> > IGP WGs have never attempted to recommend (let alone normatively define)
> any relationship between DSCP and MT.
> >
> > ???
> >
> >Les
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Toerless Eckert
> > > Sent: Wednesday, November 14, 2018 6:29 PM
> > > To: lsr@ietf.org
> > > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q
> > >
> > > Whats the current best guidance on using DSCP for selection of path,
> > > specifically for selection of topology with MTR (RFCs 4915, 5120,
> 7722) ?
> > >
> > > My understanding from history is that this looked like a good idea
> > > to customers first, but when implementations became available,
> > > customers really did not want to implement it because of the
> overloading
> > > of DSCP between QoS and routing and the resulting management
> > > complexity.
> > >
> > > Has the idea of using DSCP for path selection been re-introduced in any
> > > later work like flex-Algos ?
> > >
> > > If there could be rough consensus that this is in general a bad idea,
> i wonder
> > > if it would be appropriate to have a short normative document from LSR
> > > defining that the use of DSCP for topology selection is historic and
> > > not recommended anymore and make this an update to above three RFCs,
> > > maybe also pointing out that there are other methods to select a
> > > topology and those remain viable:
> > >
> > > I specifically would not like to see the actual MTR RFCs to be changed
> > > in status, because MTR actually does work quite well and is supported
> > > in products and deployed with IP multicast, even with multiple
> > > topologies for IP multicast in live-live scenarios.
> > >
> > > Thanks!
> > > Toerless
> > >
> > > ___
> > > 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
>
> --
> ---
> t...@cs.fau.de
>
> ___
> 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] LSR: Using DSCP for path/topology selection Q

[Toerless Eckert]

Thanks, Les, Peter

So... is there any opinion about creating a normative or BCP recommendation to
not use DSCP to distinguish topologies/flex-algos ? Mabybe this would
not be appropriate for LSR, but TSVWG, but i think it would be
participants in LSR that would know if there is actually still any
customer demand for this option.

Cheers
Toerless

P.S.: Context of the email is DetNet trying to define what a DetNet flow
is and currently this includes the thinking that DetNet flows could be
6-tuple flows including DSCP because different DSCP could be routed
differently in the network via MTR, and that concept IMHO would just
result in making a foal (DetNet) a lot more complex because of a dead
horse (DSCP MTR).

On Thu, Nov 15, 2018 at 04:41:06AM +, Les Ginsberg (ginsberg) wrote:
> Toerless -
> 
> It's pretty hard to understand the context for your email.
> 
> What leads you to believe that any of the MT specifications you mention say 
> anything normative about DSCP and topologies??
> 
> RFC4915 does not mention DSCP at all - but does make the statement:
> 
> https://tools.ietf.org/html/rfc4915#section-3.8
> "It is outside of the scope of this document to specify how the
>information in various topology specific forwarding structures are
>used during packet forwarding or how incoming packets are associated
>with the corresponding topology."
> 
> RFC 5120 does mention DSCP, but only as an example of something that "could" 
> be used to determine on what topology a packet should be forwarded.
> 
> RFC 7722 also mentions DSCP as an example, but there is a statement in 
> Section 3:
> 
> "It is assumed, but
>outside the scope of this specification, that the network layer is
>able to choose which topology to use for each packet"
> 
> IGP WGs have never attempted to recommend (let alone normatively define) any 
> relationship between DSCP and MT.
> 
> ???
> 
>Les
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Toerless Eckert
> > Sent: Wednesday, November 14, 2018 6:29 PM
> > To: lsr@ietf.org
> > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q
> > 
> > Whats the current best guidance on using DSCP for selection of path,
> > specifically for selection of topology with MTR (RFCs 4915, 5120, 7722) ?
> > 
> > My understanding from history is that this looked like a good idea
> > to customers first, but when implementations became available,
> > customers really did not want to implement it because of the overloading
> > of DSCP between QoS and routing and the resulting management
> > complexity.
> > 
> > Has the idea of using DSCP for path selection been re-introduced in any
> > later work like flex-Algos ?
> > 
> > If there could be rough consensus that this is in general a bad idea, i 
> > wonder
> > if it would be appropriate to have a short normative document from LSR
> > defining that the use of DSCP for topology selection is historic and
> > not recommended anymore and make this an update to above three RFCs,
> > maybe also pointing out that there are other methods to select a
> > topology and those remain viable:
> > 
> > I specifically would not like to see the actual MTR RFCs to be changed
> > in status, because MTR actually does work quite well and is supported
> > in products and deployed with IP multicast, even with multiple
> > topologies for IP multicast in live-live scenarios.
> > 
> > Thanks!
> > Toerless
> > 
> > ___
> > 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

-- 
---
t...@cs.fau.de

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

Re: [Lsr] draft-ietf-ospf-ospfv3-segment-routing-extensions - small change

[Acee Lindem (acee)]

Hi Peter, 
I agree - it is not needed in OSPFv3 Extended LSAs.

Hi Dirk, Mahendra, 

How will this impact your implementations?

Thanks,
Acee

On 11/15/18, 9:48 AM, "Lsr on behalf of Peter Psenak (ppsenak)" 
 wrote:

Hi,

as a part of the RtgDir review we got a comment about the usage of the 
IA bit in the OSPFv3 Extended Prefix Range TLV (Section 5).

We defined this bit for OSPFv2 originally. In OSPFv2 Extended Prefix 
Range TLV is carried as a top level TLV of the Extended Prefix Opaque 
LSA, which is not specific to any route-type, so we needed a mechanism 
to prevent redundant flooding of Prefix Range TLVs between areas.

In OSPFv3 however, we are advertising the Extended Prefix Range TLV in 
the type specific LSAs, so we can use standard rules to prevent the 
"looping" of advertisements.

So we want to remove the IA bit from the flags field in OSPFv3 Extended 
Prefix Range TLV.

I would like to know whether anyone has any objection.

thanks,
Peter

___
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] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[Acee Lindem (acee)]

Authors, 
Please note that you need not wait until the end of the adoption poll to 
address my comment and Julien's comments. 
Thanks,
Acee 

On 11/15/18, 10:02 AM, "Lsr on behalf of julien.meu...@orange.com" 
 wrote:

Hi,

Contributor hat on, I take the opportunity mentioned by Acee to
highlight some of the issues in the current version:
- The I-D teaches multiple time about RFC 5088 and 5089 (while 8253 is
only mentioned in the introduction): the discussed mechanism has been
used multiple times, there is no need to elaborate so much (see section
3.1.1 of RFC 8306 for example);
- Section 3 includes the PCE-CAP-FLAGS sub-TLV definition: having a
given specification in multiples places brings no value but may create
discrepancies, please stick to the references to the aforementioned RFCs;
- Section 3 tries to list the existing flag allocations: these are
inaccurate (e.g. RFC 6006 has been obsoleted by RFC 8306), incomplete
(e.g. RFC 8231 is missing) and inappropriate (this is the role of the
IANA registry, not of every new I-D!);
- Contrary to the written text, the I-D does not "extend" anything, it
requests bit allocation from an existing registry; the IANA section (7)
is thus key: please make it point to the relevant registry, namely "PCE
Capability Flags" managed within the "OSPFv2 Parameters"

(https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14).

Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
> Note the authors may refresh the draft to address some comments prior
> to that time. 



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
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] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[julien.meuric]

Hi,

Contributor hat on, I take the opportunity mentioned by Acee to
highlight some of the issues in the current version:
- The I-D teaches multiple time about RFC 5088 and 5089 (while 8253 is
only mentioned in the introduction): the discussed mechanism has been
used multiple times, there is no need to elaborate so much (see section
3.1.1 of RFC 8306 for example);
- Section 3 includes the PCE-CAP-FLAGS sub-TLV definition: having a
given specification in multiples places brings no value but may create
discrepancies, please stick to the references to the aforementioned RFCs;
- Section 3 tries to list the existing flag allocations: these are
inaccurate (e.g. RFC 6006 has been obsoleted by RFC 8306), incomplete
(e.g. RFC 8231 is missing) and inappropriate (this is the role of the
IANA registry, not of every new I-D!);
- Contrary to the written text, the I-D does not "extend" anything, it
requests bit allocation from an existing registry; the IANA section (7)
is thus key: please make it point to the relevant registry, namely "PCE
Capability Flags" managed within the "OSPFv2 Parameters"
(https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14).

Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
> Note the authors may refresh the draft to address some comments prior
> to that time. 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Lsr] draft-ietf-ospf-ospfv3-segment-routing-extensions - small change

[Peter Psenak]

Hi,

as a part of the RtgDir review we got a comment about the usage of the 
IA bit in the OSPFv3 Extended Prefix Range TLV (Section 5).


We defined this bit for OSPFv2 originally. In OSPFv2 Extended Prefix 
Range TLV is carried as a top level TLV of the Extended Prefix Opaque 
LSA, which is not specific to any route-type, so we needed a mechanism 
to prevent redundant flooding of Prefix Range TLVs between areas.


In OSPFv3 however, we are advertising the Extended Prefix Range TLV in 
the type specific LSAs, so we can use standard rules to prevent the 
"looping" of advertisements.


So we want to remove the IA bit from the flags field in OSPFv3 Extended 
Prefix Range TLV.


I would like to know whether anyone has any objection.

thanks,
Peter

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

Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[julien.meuric]

Hi all,

PCE chair hat on, I need to rectify the statement below: at this stage,
PCE, as a WG, has not reach any consensus on this I-D, which has only
been discussed within the LSR WG. There may be individuals involved in
both WGs, but that is not a PCE WG consensus.

However, I suggest that the PCE WG's members (BCC'd) share their view on
this poll using the LSR mailig list.

Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
>
> At the LSR WG meeting in Bangkok, there was general agreement that we
> should adopt this draft given that the PCE WG believes it is useful.
> Please indicate your support or objection prior to 12:00 AM UT,
> Wednesday November 26^th , 2018. Note the authors may refresh the
> draft to address some comments prior to that time.
>
>  
>
>  
>
> Thanks,
>
> Acee
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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