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

[Uma Chunduri]

A quick comment below –

Cheers & have a great weekend!

--
Uma C.


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, November 16, 2018 12:15 AM
To: Robert Raszuk 
Cc: t...@cs.fau.de; Les Ginsberg (ginsberg) ; r...@rob.sh; 
tony1ath...@gmail.com; lsr@ietf.org
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q

Robert,

match DSCP X
set context Y or plane Z doesn’t make it any different.
It has been used and abused in any possible way. If you want to write a BCP 
saying - use it for X/Y/Z but not for A/B/C because of - your business.

As to using it someplace else - I’d expect respective documents to cover the 
use, flex-algo drafts as to your example.

More fundamentally, (flex-algo is the best example) we have got context aware 
metadata in a form of: MPLS labels (SR SID), v6 EHs, plethora of overlay 
encaps, etc, with accompanying CP extensions that can be used to achieve 
exactly that.

Now tell me - why again DSCP?

P.S. in my previous life, working on 5G transport slicing (yes, i know :)) - i 
needed per slice identity over the common transport, we ended up looking at UDP 
port ranges, rather than DSCP - too few bits


[Uma]: +1 and was part of that previous life. May be it should be called as “4G 
slicing” and it’s deployed in few places.  Any ways it’s all about how to map 
the incoming traffic at PE (in the above case at CSR/P-GW) to a particular LSP. 
I didn’t see any requirement which needs an MTR/flex-algo aka 
light-weight-sub-topology which needs to be built based on DSCP.

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

[Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-reverse-metric-16: (with COMMENT)

[Benjamin Kaduk]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-reverse-metric-16: 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-isis-reverse-metric/



--
COMMENT:
--

Section 1

Perhaps expand IIH on first usage?

Section 1.2

(We could perhaps use "virtual network" instead of "VPN", to avoid
ambiguity about whether its traffic is encrypted.  This is quite tangential
to the actual document, so feel free to ignore.)

Section 1.5

Using an offset implies a need to do bounds checking and/or clamping.
Section 2 discusses this to some extent, though it may be worth an
additional mention here or in the security considerations.

Section 2

   The Reverse Metric TLV is a new TLV to be used inside IS-IS Hello
   PDU.  This TLV is used to support the IS-IS Reverse Metric mechanism
   that allows a "reverse metric" to be send to the IS-IS neighbor.

nits: "inside an IS-IS Hello PDU"; "sent"

Do we need to say "network byte order" for the Metric field?

The W bit seems to allow one node to modify the metric for traffic to
adjacent nodes, which is a slightly broader permission than what is
described in the security considerations and could merit mention therein.
(The existing text there on authentication should suffice even for this
permission, though.)

   U bit (0x02): The "Unreachable" bit specifies that the metric
   calculated by addition of the reverse metric value to the "default
   metric" is limited to (2^24-1).

Does this mean that 2^24-1 is the maximum value (as opposed to the maximum
of 2^24-2 when the bit is not set) or that it is the only allowed value?

   [...] This sub-TLV is optional, if it appears
   more than once then the entire Reverse Metric TLV MUST be ignored.

nit: comma splice

Section 3.2

   When an M-ISIS router
   receives a Reverse Metric TLV, it MUST add the received Metric value
   to its Default Metric in all Extended IS Reachability TLVs for all
   topologies. [...]

(I assume this is still scoped to the link in question.  I don't know
whether there's any need to add more text to clarify that, though.)

Section 3.3

 If a DIS is configured to apply Traffic Engineering over a link
   and it receives metric sub-TLV in a Reverse Metric TLV, it should
   update the Traffic Engineering Default Metric sub-TLV value of the
   corresponding Extended IS Reachability TLV or insert a new one if not
   present.

Is "metric sub-TLV" short for "Traffic Engineering Default Metric sub-TLV"?

   In the case of multi-access LANs, the "W" Flags bit is used to signal
   from a non-DIS to the DIS whether to change the metric and,
   optionally Traffic Engineering parameters for all nodes in the
   Pseudonode LSP or solely the node on the LAN originating the Reverse
   Metric TLV.

nit: comma after "optionally"

When the DIS receives the Reverse Metric TLV with the 'W' bit set, does
that mean it ignores any such TLVs it receives without the 'W' bit set, or
would both the global and router-specific offsets be applied?

Section 3.5

Please expand CSPF on first use.  (Also, nit-level, I am inferring that "a
CSPF recalculation" would be more grammatical, but am not entirely sure.)

Also, SHOULD and RECOMMENDED have the same strength, so from an editorial
perspective the current text could be consolidated.  But perhaps the intent
was to have the 2^24-1 case be a stronger requirement, in which case MUST
could be used?

   It is RECOMMENDED that implementations provide a capability to
   disable any IS-IS metric changes by Reverse Metric mechanism through
   neighbor's Hello PDUs.  It can be to a node's individual interface
   Default Metric or Traffic Engineering parameters based upon receiving
   a properly formatted Reverse Metric TLVs.

I'm failing to parse this last sentence.  The first sentence seems to be
saying that implementations should provide a knob to ignore received
Reverse Metric TLVs, so maybe the second sentence is trying to say what the
behavior would be in the case that the received Reverse Metric TLV is
ignored?  I'm not sure.

Section 4

 The enhancement in this document makes
   it possible for one IS-IS router to manipulate the IS-IS Default
   Metric and, optionally, Traffic Engineering parameters of adjacent
   IS-IS neighbors. [...]

Just to check my understanding: this manipulation is for parameters either
for links directed at the IS-IS router sending Reverse 

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Alvaro Retana]

[Took the ops-dir and the ietf@ietf lists off.]

Hi!

Joe makes a really good point below about the TLV types and RFC7770.  It
looks like we all missed it! :-(

To quote Peter (from a message in this thread), "I don't think it is good
to specify the behavior which is described somewhere else.”

Looking at -18, Section 4
(draft-ietf-ospf-ospfv3-segment-routing-extensions) has the exact same text
[*] as Section 3 in draft-ietf-ospf-segment-routing-extensions.  Given that
the IANA allocation is done in draft-ietf-ospf-segment-routing-extensions,
and that draft-ietf-ospf-ospfv3-segment-routing-extensions refers back to
it, then I would like to see the following changes:

(1) In draft-ietf-ospf-segment-routing-extensions, Section 3:


These SR capabilities are advertised in the Router Information Opaque LSA
(defined in [RFC7770]).


These SR capabilities are advertised in the Router Information Opaque LSA
(defined in [RFC7770]).  The TLVs defined below are applicable to both
OSPFv2 and OSPFv3; see also
[ID.ietf-ospf-ospfv3-segment-routing-extensions].

…and add an Informative reference to
draft-ietf-ospf-ospfv3-segment-routing-extensions.

(2) In draft-ietf-ospf-ospfv3-segment-routing-extensions, replace the
entire Section 4 with:

"
Segment Routing requires some additional router capabilities to be
advertised to other routers in the area.

These SR capabilities are advertised in the OSPFv3 Router Information
Opaque LSA (defined in [RFC7770]), and specified in
[ID.ietf-ospf-segment-routing-extensions].
“


Even though draft-ietf-ospf-segment-routing-extensions is already with the
RFC Editor, it is waiting for draft-ietf-spring-segment-routing-mpls, so we
can still make changes.  Please submit a new version (and send an update of
the XML to the rfc-editor).

I am scheduling draft-ietf-ospf-ospfv3-segment-routing-extensions on the
Dec/6 IESG Telechat.  Please submit an update before the end of this month.

Thanks!!

Alvaro.



[*] Except for the OSPFv3 being specifically called out, and a couple of
other minor points.

On October 30, 2018 at 8:05:27 AM, Peter Psenak (ppse...@cisco.com) wrote:

> With respect to TLV types 8, 9, 14, and 15, they are defined in
> draft-ietf-ospf-segment-routing-extensions, and it took me a while to
figure
> out where you were getting those values and why they weren't spelled out
in the
> IANA considerations. You have a normative reference to this, which is
good,
> but you only mention it with respect to the algorithm parameters. I think
> another mention is required.
>
> I'm going to be pedantic here. According to RFC7770, when a new OSPF
Router
> Information LSA TLV is defined, the spec needs to explicitly state if it's

> applicable to OSPFv2, v3, or both. While you reference the TLVs from
> draft-ietf-ospf-segment-routing-extensions, I didn't see that either
document
> _explicitly_ states that they are applicable to both.

##PP
added the following to each of the values:

Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and
aplicable to OSPFv3.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Alvaro Retana]

Peter:

Hi!

-18 still has one reference to the IA-flag in §8.1.  Please remove it.

Thanks!

Alvaro.

On November 16, 2018 at 1:20:18 AM, Mahendra Singh Negi (
mahendrasi...@huawei.com) wrote:

Hi Acee/Peter,

This change doesn't impact our implementation.

Thanks,
Mahendra

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: 15 November 2018 20:55
To: Peter Psenak (ppsenak) ; lsr@ietf.org
Cc: Goethals, Dirk (Nokia - BE/Antwerp) ; Mahendra
Singh Negi 
Subject: Re: [Lsr] draft-ietf-ospf-ospfv3-segment-routing-extensions -
small change

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)" <
lsr-boun...@ietf.org on behalf of ppse...@cisco.com> 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Genart last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-18

[Peter Psenak]

Hi Pete,

please see inline:

On 16/11/18 14:45 , Pete Resnick wrote:

Reviewer: Pete Resnick
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-ospfv3-segment-routing-extensions-18
Reviewer: Pete Resnick
Review Date: 2018-11-16
IETF LC End Date: 2018-11-16
IESG Telechat date: Not scheduled for a telechat

Summary: One serious concern, one minor issue, and some nits.

Major issues:

In 3.1:

I get worried when I see this:

   SID/Label: If length is set to 3, then the 20 rightmost bits
   represent a label.

So, the Length is not a length, but rather a flag. This seems like it has the
potential for an interop problem. If a general implementation treats it as a
length, it's going to get the left-most 24 bits when the value is 3. Even if
the implementation chooses the right-most 24 bits, it's only supposed to take
the right-most 20 bits and mask off the extra 4 bits. Or are you going to
specify that implementations must always set the extra 4 bits to 0?


no. We have other documents that use the same and none of them enforces 
the other bits to 0. When we say we only use specific bits, the rest can 
be set to anything.




Maybe this sort of thing is the way things have always been done for TLVs, and
if so feel free to ignore me, but from an code implementation perspective, this
seems like an accident waiting to happen. (Known sometimes as a "foot-gun".)

Minor issues:

In 4.4:

The SRMS Preference TLV MAY only be advertised once in the OSPFv3
Router Information Opaque LSA and has the following format:

You mean MUST, not MAY there.


sure, I will change to MUST.



In 7.1 and 7.2:

If SID/Index/Label is a label, is it using the low 20 bits of the first 3 bytes
of the field (i.e., bits 4-23)?


right.


Is there a requirement that the high 4 bits and
the low 8 bits must be cleared by the implementation?


there is no such requirement really.


Some clarification would be useful.

In 8.1:

You talk about setting the IA-flag, but this version of the document doesn't
define the IA-flag anymore. Is it defined elsewhere?


my bad, we have removed IA in last version, but I forgot to remove this 
part. I removed it.




Nits/editorial comments:

In 3.1:

Ignoring the issue stated above, I also found this text a bit confusing:

   Length: Variable, 3 or 4 octets

Obviously you mean that the value of Length is either 3 or 4. At first I read
it as the value of Length was variable, and that it took up 3 or 4 octets in
the Sub-TLV. If this is the way you've always written these things, fine, but
it seems to me it would be clearer to say.

   Length: Either 3 or 4


Done.




In 5:

s/we need a single advertisement/a single advertisement is needed

Just being pedantic. If you like it, use it. If not, don't.


Done.

Please let me know if you agree or disagree with my responses.

thanks,
Peter




.



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

[Lsr] Genart last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-18

[Pete Resnick]

Reviewer: Pete Resnick
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-ospfv3-segment-routing-extensions-18
Reviewer: Pete Resnick
Review Date: 2018-11-16
IETF LC End Date: 2018-11-16
IESG Telechat date: Not scheduled for a telechat

Summary: One serious concern, one minor issue, and some nits.

Major issues:

In 3.1:

I get worried when I see this:

  SID/Label: If length is set to 3, then the 20 rightmost bits
  represent a label.

So, the Length is not a length, but rather a flag. This seems like it has the
potential for an interop problem. If a general implementation treats it as a
length, it's going to get the left-most 24 bits when the value is 3. Even if
the implementation chooses the right-most 24 bits, it's only supposed to take
the right-most 20 bits and mask off the extra 4 bits. Or are you going to
specify that implementations must always set the extra 4 bits to 0?

Maybe this sort of thing is the way things have always been done for TLVs, and
if so feel free to ignore me, but from an code implementation perspective, this
seems like an accident waiting to happen. (Known sometimes as a "foot-gun".)

Minor issues:

In 4.4:

   The SRMS Preference TLV MAY only be advertised once in the OSPFv3
   Router Information Opaque LSA and has the following format:

You mean MUST, not MAY there.

In 7.1 and 7.2:

If SID/Index/Label is a label, is it using the low 20 bits of the first 3 bytes
of the field (i.e., bits 4-23)? Is there a requirement that the high 4 bits and
the low 8 bits must be cleared by the implementation? Some clarification would
be useful.

In 8.1:

You talk about setting the IA-flag, but this version of the document doesn't
define the IA-flag anymore. Is it defined elsewhere?

Nits/editorial comments:

In 3.1:

Ignoring the issue stated above, I also found this text a bit confusing:

  Length: Variable, 3 or 4 octets

Obviously you mean that the value of Length is either 3 or 4. At first I read
it as the value of Length was variable, and that it took up 3 or 4 octets in
the Sub-TLV. If this is the way you've always written these things, fine, but
it seems to me it would be clearer to say.

  Length: Either 3 or 4

In 5:

   s/we need a single advertisement/a single advertisement is needed

Just being pedantic. If you like it, use it. If not, don't.


___
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)]

Hi Qin, 

This was at a time when there were concerns about advertising non-IGP specific 
information in OSPF(v3) Router Information LSAs. We've since assuaged our 
concerns with RFC 7770 where I added the functionality  of advertising multiple 
instances of the OSPF(v3) Router Information LSA. Note that this new draft 
should update both RFC 5088 and RFC 5089. 

Thanks,
Acee 

On 11/16/18, 12:01 AM, "Qin Wu"  wrote:

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
 

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

[Acee Lindem (acee)]

Hi Qin,
This looks more like applying a mechanism analogous to BGP capabilities 
negotiation to PCC<->PCE. However, please check and file the necessary IPR 
disclosure if applicable.
Thanks,
Acee

From: Qin Wu 
Date: Friday, November 16, 2018 at 2:44 AM
To: Acee Lindem , draft-wu-lsr-pce-discovery-security-support 

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

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

[Lsr] I-D Action: draft-ietf-ospf-ospfv3-segment-routing-extensions-18.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPFv3 Extensions for Segment Routing
Authors : Peter Psenak
  Stefano Previdi
Filename: 
draft-ietf-ospf-ospfv3-segment-routing-extensions-18.txt
Pages   : 27
Date: 2018-11-16

Abstract:
   Segment Routing (SR) allows a flexible definition of end-to-end paths
   within IGP topologies by encoding paths as sequences of topological
   sub-paths, called "segments".  These segments are advertised by the
   link-state routing protocols (IS-IS and OSPF).

   This draft describes the OSPFv3 extensions required for Segment
   Routing with MPLS data plane.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-18
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-segment-routing-extensions-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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:14:45AM -0800, Jeff Tantsura wrote:
> P.S. in my previous life, working on 5G transport slicing (yes, i know :))
> - i needed per slice identity over the common transport, we ended up
> looking at UDP port ranges, rather than DSCP - too few bits

Right. The main issue is when you start requiring new/more DSCP for
a purpose that is not QoS. Which by itself is not a good hard
definition, but at least a starting point.

Cheers
Toerless

> 
> Cheers,
> Jeff
> On Thu, Nov 15, 2018 at 23:37 Robert Raszuk  wrote:
> 
> > 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


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

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

Rob,

Thats actually a good example, i had forgotten about that one.
This is also a lot more scalable than MTR given how (if i
remember correctly, you would only have  O(#DSCP,#egres-PE)
entries.

Cheers
Toerless

On Thu, Nov 15, 2018 at 04:47:26PM -0800, 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] LSR: Using DSCP for path/topology selection Q

[Jeff Tantsura]

Robert,

match DSCP X
set context Y or plane Z doesn’t make it any different.
It has been used and abused in any possible way. If you want to write a BCP
saying - use it for X/Y/Z but not for A/B/C because of - your business.

As to using it someplace else - I’d expect respective documents to cover
the use, flex-algo drafts as to your example.

More fundamentally, (flex-algo is the best example) we have got context
aware metadata in a form of: MPLS labels (SR SID), v6 EHs, plethora of
overlay encaps, etc, with accompanying CP extensions that can be used to
achieve exactly that.

Now tell me - why again DSCP?

P.S. in my previous life, working on 5G transport slicing (yes, i know :))
- i needed per slice identity over the common transport, we ended up
looking at UDP port ranges, rather than DSCP - too few bits

Cheers,
Jeff
On Thu, Nov 15, 2018 at 23:37 Robert Raszuk  wrote:

> 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