[spring] 答复: IPR Poll for draft-filsfils-spring-srv6-network-programming

[Xiazhongqi (Sam, Router & Carrier Ethernet Solution Arch Department)]

please ignore my request.  Sorry for the noise.

Thx,
Sam

发件人: Xiazhongqi (Sam, Router & Carrier Ethernet Solution Arch 
Department)
发送时间: Thursday, April 11, 2019 9:22 AM
收件人: 'Hani Elmalky' ; Stefano Salsano 

抄送: bruno.decra...@orange.com; SPRING WG ; 
draft-filsfils-spring-srv6-network-programm...@ietf.org
主题: 答复: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming

Hi Bruno,

I think that Clarence should clarify the IPR issue by himself.

Thx,
Sam

发件人: Hani Elmalky [mailto:hani.elma...@gmail.com]
发送时间: Thursday, April 11, 2019 1:15 AM
收件人: Stefano Salsano 
mailto:stefano.sals...@uniroma2.it>>
抄送: bruno.decra...@orange.com; SPRING WG 
mailto:spring@ietf.org>>; 
draft-filsfils-spring-srv6-network-programm...@ietf.org
主题: Re: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming

[https://mailtrack.io/trace/mail/462f5230078139ad463844c2d7f62abc67d9b740.png?u=3278937]I'm
 not aware of any IPR that apply to that draft.

/ Hani Elmalky


On Thu, Apr 4, 2019 at 8:17 AM Stefano Salsano 
mailto:stefano.sals...@uniroma2.it>> wrote:
I am not aware of any IPR that apply to this draft

Stefano Salsano

Il 2019-03-13 19:50, 
bruno.decra...@orange.com ha scritto:
> Hi authors, SPRING WG,
>
> In parallel to the call for adoption for
> draft-filsfils-spring-srv6-network-programming (1), we would like to
> poll for IPR.
>
> If you are aware of IPR that applies to
> draft-filsfils-spring-srv6-network-programming please respond to this email.
>
> If you are aware of IPR, please indicate whether it has been disclosed
> in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378
> provide more details).
>
> If you are an *author or contributor* please respond to this email
> regardless of whether or not you're aware of any IPR.
>
> If you are not an author or contributor, please explicitly respond only
> if you are aware of IPR that has not yet been disclosed.
>
> This document will not advance into the working group until IPR
> confirmations have been received from all authors and contributors.
>
> Thank you,
>
> (1)https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07
>
> --Bruno & Rob.
>
> _
>
> 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.
>


--
***
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : stefano.sals...@uniroma2.it
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
***

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

[spring] Suresh Krishnan's No Objection on draft-ietf-spring-segment-routing-mpls-19: (with COMMENT)

[Suresh Krishnan via Datatracker]

Suresh Krishnan has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: 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-spring-segment-routing-mpls/



--
COMMENT:
--

* Section 2

"including for TI-LFA".

Add a reference to draft-bashandy-rtgwg-segment-routing-ti-lfa at first use?

* Section 2.4

Calling "temp" something more descriptive would have been helpful (say
base_index).

* Section 2.5.1.

"Address Family represented by 8 bits, where IPv4 encoded as 100 and IPv6 is
encoded as 110."

Suggest rewording to say IPv4 is represented by the value 4 and IPv6 is
represented by the value 6 (unless you actually meant to use the decimal values
100 and 110, in which case ignore this comment).


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

[spring] 答复: IPR Poll for draft-filsfils-spring-srv6-network-programming

[Xiazhongqi (Sam, Router & Carrier Ethernet Solution Arch Department)]

Hi Bruno,

I think that Clarence should clarify the IPR issue by himself.

Thx,
Sam

发件人: Hani Elmalky [mailto:hani.elma...@gmail.com]
发送时间: Thursday, April 11, 2019 1:15 AM
收件人: Stefano Salsano 
抄送: bruno.decra...@orange.com; SPRING WG ; 
draft-filsfils-spring-srv6-network-programm...@ietf.org
主题: Re: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming

[https://mailtrack.io/trace/mail/462f5230078139ad463844c2d7f62abc67d9b740.png?u=3278937]I'm
 not aware of any IPR that apply to that draft.

/ Hani Elmalky


On Thu, Apr 4, 2019 at 8:17 AM Stefano Salsano 
mailto:stefano.sals...@uniroma2.it>> wrote:
I am not aware of any IPR that apply to this draft

Stefano Salsano

Il 2019-03-13 19:50, 
bruno.decra...@orange.com ha scritto:
> Hi authors, SPRING WG,
>
> In parallel to the call for adoption for
> draft-filsfils-spring-srv6-network-programming (1), we would like to
> poll for IPR.
>
> If you are aware of IPR that applies to
> draft-filsfils-spring-srv6-network-programming please respond to this email.
>
> If you are aware of IPR, please indicate whether it has been disclosed
> in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378
> provide more details).
>
> If you are an *author or contributor* please respond to this email
> regardless of whether or not you're aware of any IPR.
>
> If you are not an author or contributor, please explicitly respond only
> if you are aware of IPR that has not yet been disclosed.
>
> This document will not advance into the working group until IPR
> confirmations have been received from all authors and contributors.
>
> Thank you,
>
> (1)https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07
>
> --Bruno & Rob.
>
> _
>
> 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.
>


--
***
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : stefano.sals...@uniroma2.it
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
***

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

[spring] Adam Roach's No Objection on draft-ietf-spring-segment-routing-mpls-19: (with COMMENT)

[Adam Roach via Datatracker]

Adam Roach has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: 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-spring-segment-routing-mpls/



--
COMMENT:
--




§2.1:

>  The MCC in the network downloads
>  different MPLS labels/SIDs to the FIB for different forwarding
>  behaviors

Please expand "FIB" on first use.


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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-exten

[Alvaro Retana]

On April 10, 2019 at 5:46:56 PM, Vigoureux, Martin (Nokia -
FR/Paris-Saclay) (martin.vigour...@nokia.com) wrote:

Martin:

Hi!

It looks to me that you don’t disagree with what is written in the draft
but rather with the fact that the draft may suggest that IGPs should do
things which are in fact not specified in the IGPs drafts. I think this
point covers 1.1 to 1.4

Assuming that I’m correct, I believe that in order to clear the
misunderstanding authors could simply remove the sentence: “IGPs with SR
extensions...are examples of MCCs.”.

…and probably clean up some other text, for example, §2.10.1
references I-D.ietf-isis-segment-routing-extensions specifically.

Bottom line, I think you’re right.

On 1.5. I don’t think there is a conflict. It does not contradict 8402. It
is not saying “An IGP Node-SID SHOULD NOT be associated with a prefix …”

The way I see it is that this is a belt and suspenders approach. The base
req says MUST NOT and this req says “check if this req is respected”.

I read this document as saying “check, but you may have reasons not to”…
 IMHO, there’s no reason to specify the behavior here again, if it’s
already specified in rfc8402.

Of course this is only my view. I expect authors to have their own.

I’m sure they will. ;-)

Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: Discuss

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-spring-segment-routing-mpls/



--
DISCUSS:
--

(pro forma) Six authors is more than five, which per RFC 7322 may require
discussion.

I have a few questions about whether we need to have more stringent or
more specific requirements listed.

In Section 2:

   An implementation SHOULD check that an IGP node-SID is not associated
   with a prefix that is owned by more than one router within the same
   routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
   another one if available, and SHOULD log an error.

While it's not entirely clear to me that we need to mandate checking
(the "SHOULD check"), I have a hard time understanding why we would
allow a known-bad SID to be used ("SHOULD NOT use this Node-SID").
Shouldn't that be a "MUST NOT", since using it could break the SR
abstraction?

In Section 2.5:

   5. The remaining FECs with the default algorithm (see the
  specification of prefix-SID algorithm [RFC8402]) are installed in
  the FIB natively, such as pure IP entries in case of Prefix FEC,
  without any incoming labels corresponding to their SIDs. The
  remaining FECs with a non-zero algorithm are not installed in the
  FIB.

I didn't really find where in RFC 8402 we assigned numerical values to
the prefix-SID algorithms, such that "non-zero algorithm" was
well-defined.  Should I be looking somewhere else for this?

In Section 2.5.1: I left several notes in the COMMENT section, but I
think I can summarize the point to "it seems like we are defining a
mapping from attributes of a given FEC/description to a byte string and
applying an ordering to that byte string.  But we don't fully specify
how all the bits are encoded in that byte string, and it looks like we
can end up with byte strings of a different length, so the comparison
rule is not necessarily clear in that case."  This seems fairly related
to Alvaro's point (2).

In Appendix A.1

   | Local IGP SID allocated dynamically by R2 |
   | for its "north" adjacency to R3: 9001 |
   | for its "north" adjacency to R3: 9003 |
   | for its "south" adjacency to R3: 9002 |
   | for its "south" adjacency to R3: 9003 |

9003 is duplicated for different adjacencies?  Isn't that a strongly
disrecommended scenario?


--
COMMENT:
--

It seems that we're introducing something of a new concept in this
document of "routing instance" as something with a numerical identifier.
(That is, this does not appear in RFC 8402 or RFC 3031, in terms of
what references I might expect to be in scope.)  Am I just missing some
other reference where this is introduced?  If not, maybe it is worth
mentioning in a terminology section.

[I think some of these section-by-section notes were spotted already;
I didn't get a chance to deduplicate.]

Section 2

   In order to have a node segment to reach the node, a network operator
   SHOULD configure at least one node segment per routing instance,
   topology, algorithm. [...]

nit: maybe "per tuple of [...]"?

Section 2.2

   o  The label value MUST be unique within the router on which the MCC
  is running. i.e. the label MUST only be used to represent the SID
  and MUST NOT be used to represent more than one SID or for any
  other forwarding purpose on the router.

Maybe I'm misreading the intent, but "MUST be unique" seems like it's a
requirement from core MPLS and need not be restated.

Section 2.3

   The rules
   applicable to the SRGB are also applicable to the SRLB, except rule
   that says that the SRGB MUST only be used to instantiate global SIDs
   into the MPLS forwarding plane. [...]

nit: "except the rule"

Section 2.4

I'd consider writing the algorithm in real code (python?) rather than
abstract pseudocode.  In some cases (though probably not here?)
pseudocode makes it easy to miss edge cases that need to be specified in
order for things to be interoperably implementable.

Section 2.5

   MPLS Architecture [RFC3031] defines Forwarding Equivalence Class
   (FEC) term as the set of packets with similar and / or 

[spring] Warren Kumari's No Objection on draft-ietf-spring-segment-routing-mpls-19: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: 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-spring-segment-routing-mpls/



--
COMMENT:
--

Thank you for a well written / easy to understand document.

I have a few suggestions / nits. Please note: If the WG has already discussed
these, and come to other decisions, I'm fine with that...

1:  "In order to have a node segment to reach the node, a network operator
SHOULD configure at least one node segment per routing instance, topology,
algorithm. " Perhaps: "segment per (routing instance, topology, algorithm)."
(or "set of ..", or "combination of..." or something - not quite sure how best
to word, but this seems slightly confusing).

2:  "If the SRGB of a node does not conform to the structure specified in this
section or to the previous two rules, then this SRGB MUST be completely ignored
by all routers in the routing domain and the node MUST be treated as if it does
not have an SRGB." Shouldn't this be logged somewhere?

" The rules applicable to the SRGB are also applicable to the SRLB, except rule
that says that the SRGB MUST only be used to instantiate global SIDs  into the
MPLS forwarding plane. The recommended, minimum, or maximum size of the SRGB
and/or SRLB is a matter of future study" 3: I think there is a missing word(s)
between 'except rule' - perhaps "for the"? 4: Missing period.

5: "For the purpose of incoming label collision resolution, a routing instance
is identified by a single incoming label downloader to FIB." - is downloader
the right word here?

6: "If the derived numerical value varies for the same configuration, then an
implementation SHOULD make numerical value used to identify a routing instance
configurable." This is a philosophical point, but it seems like I might always
want to be able to configure this -- perhaps just "Implementations SHOULD
make...? "

7: "This document defines the default tie breaking rules that SHOULD be
implemented. An implementation MAY choose to support different tie-breaking
rules and MAY use one of the these instead of the default tie-breaking rules.
All routers in a routing domain SHOULD use the same tie-breaking rules to
maximize forwarding consistency." Is there any reason not to require that all
implementations implement these rules (mandatory to implement)? I don't want to
end up in a situation where I buy boxes from Vendor X, and then cannot add
Vendor Y, because they don't share a set of rules.

8:  "R2 is the next-hop along the shortest path towards R8. By applying the
steps in Section 2.8 the outgoing label downloaded to R1’s FIB corresponding to
the global SID index 8 is 1008 because the SRGB of R2 is [1000,5000] as shown
in Figure 2." - I was initially confused by the [1000,5000] as it isn't
represented like this in the figure. Perhaps change either this text, or the
text in the figure?


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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-exten

[Vigoureux, Martin (Nokia - FR/Paris-Saclay)]

Alvaro,

Thanks for your review. I’m not sure whether I should reply here or on the 
iesg’s list.
It looks to me that you don’t disagree with what is written in the draft but 
rather with the fact that the draft may suggest that IGPs should do things 
which are in fact not specified in the IGPs drafts. I think this point covers 
1.1 to 1.4
Assuming that I’m correct, I believe that in order to clear the 
misunderstanding authors could simply remove the sentence: “IGPs with SR 
extensions...are examples of MCCs.”.

On 1.5. I don’t think there is a conflict. It does not contradict 8402. It is 
not saying “An IGP Node-SID SHOULD NOT be associated with a prefix …”
The way I see it is that this is a belt and suspenders approach. The base req 
says MUST NOT and this req says “check if this req is respected”.

Of course this is only my view. I expect authors to have their own.

-m


From: Alvaro Retana 
Sent: Wednesday, April 10, 2019 22:31
To: draft-ietf-spring-segment-routing-mpls@ietf.org; 
draft-ietf-ospf-segment-routing-extensions@ietf.org; 
draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org; 
draft-ietf-isis-segment-routing-extensions@ietf.org
Cc: SPRING WG ; l...@ietf.org
Subject: Fwd: Alvaro Retana's Discuss on 
draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) 
(draft-ietf-ospf-segment-routing-extensions / 
draft-ietf-ospf-ospfv3-segment-routing-extensions / 
draft-ietf-isis-segment-routing-extensions)

Hi!

I just entered a DISCUSS position related to 
draft-ietf-spring-segment-routing-mpls (see below).  I believe that the issue 
needs to be solved in conjunction with the IGP extension drafts, so I’m copying 
the authors/shepherds/chairs here.

Thanks!

Alvaro.


On April 10, 2019 at 4:25:22 PM, Alvaro Retana via Datatracker 
(nore...@ietf.org) wrote:
--
DISCUSS:
--

(1) This first point is a cross-document DISCUSS. In short, the assumptions in
this document about what an MCC is responsible for are not in line with the
corresponding IGP drafts for OSPF [1][2] and IS-IS [3]. This misalignment must
be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
Chairs and ADs. Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control Plane
Client (MCC)" any control plane entity installing forwarding entries in the
MPLS data plane. IGPs with SR extensions...are examples of MCCs."

The focus of the IGP drafts is on the transport of the SR information, and not
on other functions (see below). Which component is responsible for what is the
point that needs clarification -- either in this document, the IGP drafts, or
both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules MUST be
applied by the MCC when calculating the MPLS label value corresponding the SID
index value "I"." There's nothing in the IGP extension documents that point at
this set of rules, and only a passing reference in the OSPF documents about
outgoing labels.

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an MCC
than what the IGP documents do. For example: "Within an MCC, apply
tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
downloading the correct label value to FIB"...in this case not just calculating
the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that PUSH
or CONTINUE operation must be applied using the SID "Si" is beyond the scope of
this document. An example of a method to determine the SID "Si" for PUSH
operation is the case where IS-IS
[I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or
the OSPF ones, for that matter) don't talk about how to determine the operation
-- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

An implementation SHOULD check that an IGP node-SID is not associated
with a prefix that is owned by more than one router within the same
routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
that is owned by more than one router within the same routing domain." The
text above is not in line with that (MUST NOT vs SHOULD). Also, how can
"SHOULD check" be Normatively enforced?

Both sentences above seem to be trying to specify a behavior for the IGPs.

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2]
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions
[3] 

[spring] Fwd: Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-exte

[Alvaro Retana]

Hi!

I just entered a DISCUSS position related
to draft-ietf-spring-segment-routing-mpls (see below).  I believe that the
issue needs to be solved in conjunction with the IGP extension drafts, so
I’m copying the authors/shepherds/chairs here.

Thanks!

Alvaro.

On April 10, 2019 at 4:25:22 PM, Alvaro Retana via Datatracker (
nore...@ietf.org) wrote:

--
DISCUSS:
--

(1) This first point is a cross-document DISCUSS. In short, the assumptions
in
this document about what an MCC is responsible for are not in line with the
corresponding IGP drafts for OSPF [1][2] and IS-IS [3]. This misalignment
must
be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
Chairs and ADs. Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control
Plane
Client (MCC)" any control plane entity installing forwarding entries in the
MPLS data plane. IGPs with SR extensions...are examples of MCCs."

The focus of the IGP drafts is on the transport of the SR information, and
not
on other functions (see below). Which component is responsible for what is
the
point that needs clarification -- either in this document, the IGP drafts,
or
both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules
MUST be
applied by the MCC when calculating the MPLS label value corresponding the
SID
index value "I"." There's nothing in the IGP extension documents that point
at
this set of rules, and only a passing reference in the OSPF documents about
outgoing labels.

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an
MCC
than what the IGP documents do. For example: "Within an MCC, apply
tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
downloading the correct label value to FIB"...in this case not just
calculating
the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that
PUSH
or CONTINUE operation must be applied using the SID "Si" is beyond the
scope of
this document. An example of a method to determine the SID "Si" for PUSH
operation is the case where IS-IS
[I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or

the OSPF ones, for that matter) don't talk about how to determine the
operation
-- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

An implementation SHOULD check that an IGP node-SID is not associated
with a prefix that is owned by more than one router within the same
routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
that is owned by more than one router within the same routing domain." The
text above is not in line with that (MUST NOT vs SHOULD). Also, how can
"SHOULD check" be Normatively enforced?

Both sentences above seem to be trying to specify a behavior for the IGPs.

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2]
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions

[3] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker]

Alvaro Retana has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: Discuss

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-spring-segment-routing-mpls/



--
DISCUSS:
--

(1) This first point is a cross-document DISCUSS.  In short, the assumptions in
this document about what an MCC is responsible for are not in line with the
corresponding IGP drafts for OSPF [1][2] and IS-IS [3].  This misalignment must
be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
Chairs and ADs.  Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control Plane
Client (MCC)" any control plane entity installing forwarding entries in the
MPLS data plane.  IGPs with SR extensions...are examples of MCCs."

The focus of the IGP drafts is on the transport of the SR information, and not
on other functions (see below).  Which component is responsible for what is the
point that needs clarification -- either in this document, the IGP drafts, or
both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules MUST be
applied by the MCC when calculating the MPLS label value corresponding the SID
index value "I"."  There's nothing in the IGP extension documents that point at
this set of rules, and only a passing reference in the OSPF documents about
outgoing labels.

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an MCC
than what the IGP documents do.  For example: "Within an MCC, apply
tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
downloading the correct label value to FIB"...in this case not just calculating
the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that PUSH
or CONTINUE operation must be applied using the SID "Si" is beyond the scope of
this document. An example of a method to determine the SID "Si" for PUSH
operation is the case where IS-IS
[I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or
the OSPF ones, for that matter) don't talk about how to determine the operation
-- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

   An implementation SHOULD check that an IGP node-SID is not associated
   with a prefix that is owned by more than one router within the same
   routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
   another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
that is owned by more than one router within the same routing domain."  The
text above is not in line with that (MUST NOT vs SHOULD).  Also, how can
"SHOULD check" be Normatively enforced?

Both sentences above seem to be trying to specify a behavior for the IGPs.

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2]
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions
[3] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions

(2) §2.5.1: According to §2.5, a "tie-breaking rule MUST be deterministic". 
However, the specification of the default rules are not: the first step uses
the administrative distance, but the specification says that "the FEC types are
ordered using the default administrative distance ordering defined by the
implementation"...and later that the "user SHOULD ensure that the same
administrative distance preference is used on all routers".  The combination of
different implementations and the lack of an absolute requirement to ensure
consistency can easily be non-deterministic.

This point is related to the text in §2.6 which talks about how "the ingress
node MUST resolve" collisions the same way.  Because of the lack of an absolute
requirement for consistency, this "MUST" doesn't guarantee the same result.

Also related is this text in §2.5.1: "All routers in a routing domain SHOULD
use the same tie-breaking rules to maximize forwarding consistency."  When
would all routers not use the same rules?  It seems to me that forwarding
consistency is very important and would want to be maximized all the time. 
IOW, why not use MUST?

I'm making this point a DISCUSS item because it is directly related to the
ability of multiple 

[spring] Deborah Brungard's No Objection on draft-ietf-spring-segment-routing-mpls-19: (with COMMENT)

[Deborah Brungard via Datatracker]

Deborah Brungard has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: 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-spring-segment-routing-mpls/



--
COMMENT:
--

Noting Mirja's comment asking why is this not Informational, I agree with the
current track "PS" as it defines (using RFC2119 keywords) SR-MPLS procedures
for an MPLS dataplane.

Section 2
(my previous Discuss point)
- 1.The text in Section 1 states “An implementation SHOULD
check that an IGP node-SID is not associated with a prefix that is owned by
more than one router within the same routing domain. If so, it SHOULD NOT use
this Node-SID, MAY use another one if available, and SHOULD log an error”.

Sasha suggested MAY/s/SHOULD or MUST,  saying MUST aligns with Section
3.2/RFC8402, which uses the wording "MUST NOT" be used by another router.

While the document was changed to "SHOULD",  my point was that I agreed with
Sasha on this, to align with RFC8402, it needs to be a "MUST".

Though reading later in RFC8402's Section 9 Manageability Considerations, I see
it uses a "SHOULD". So I'll defer to the authors/working group on their
preference.

On my previous Discuss, I asked how does an implementation "check"?
In RFC8402's Manageability Considerations, it says "In addition to the
allocation policy/tooling that the operator will have in place, an
implementation SHOULD protect the network in case of conflict detection by
providing a deterministic resolution approach." So while I prefer RFC8402's
more explicit operational guidance vs. "check", I'll defer to the authors. My
concern is not so much for MPLS operators, this is nothing new, but to say
something more accurate than "check" in an RFC.

Nit (overall)
I was surprised/disappointed there was no alignment on terminology with
RFC8402. For example, RFC8402 defines terms for SR MPLS, e.g. SR-MPLS, but this
document doesn't use any of RFC8402's defined MPLS terms.

Suggestion at minimum a fix for the Abstract:
Segment Routing (SR) leverages the source routing paradigm.
/s/
Segment Routing (SR) leverages the source routing paradigm as defined in
[RFC8402]. And: This document specifies the forwarding behavior to allow
instantiating SR over the MPLS dataplane. /s/ This document specifies the
forwarding behavior to allow instantiating SR over the MPLS dataplane (SR-MPLS).

Nit: Section 2
I had difficulty parsing the first bullet:
>From a control plane perspective, [RFC3031] does not mandate a single signaling
protocol.  Segment Routing makes use of various control plane protocols such as
link state IGPs [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding mechanisms of
link state IGPs fits very well with label stacking on ingress. Future control
layer protocol and/or policy/configuration can be used to specify the label
stack. /suggest/ From a control plane perspective, [RFC3031] does not mandate a
single control protocol or use of a control protocol. Segment Routing makes use
of various control plane protocols such as link state IGPs
[I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Future control layer
protocols are not precluded and/or management policy/configuration can be used
to specify the label stack.


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

Re: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming

[Hani Elmalky]

I'm not aware of any IPR that apply to that draft.

/ Hani Elmalky


On Thu, Apr 4, 2019 at 8:17 AM Stefano Salsano 
wrote:

> I am not aware of any IPR that apply to this draft
>
> Stefano Salsano
>
> Il 2019-03-13 19:50, bruno.decra...@orange.com ha scritto:
> > Hi authors, SPRING WG,
> >
> > In parallel to the call for adoption for
> > draft-filsfils-spring-srv6-network-programming (1), we would like to
> > poll for IPR.
> >
> > If you are aware of IPR that applies to
> > draft-filsfils-spring-srv6-network-programming please respond to this
> email.
> >
> > If you are aware of IPR, please indicate whether it has been disclosed
> > in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378
> > provide more details).
> >
> > If you are an *author or contributor* please respond to this email
> > regardless of whether or not you're aware of any IPR.
> >
> > If you are not an author or contributor, please explicitly respond only
> > if you are aware of IPR that has not yet been disclosed.
> >
> > This document will not advance into the working group until IPR
> > confirmations have been received from all authors and contributors.
> >
> > Thank you,
> >
> > (1)
> https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07
> 
> >
> > --Bruno & Rob.
> >
> >
> _
> >
> > 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.
> >
>
>
> --
> ***
> Stefano Salsano
> Professore Associato
> Dipartimento Ingegneria Elettronica
> Universita' di Roma Tor Vergata
> Viale Politecnico, 1 - 00133 Roma - ITALY
>
> http://netgroup.uniroma2.it/Stefano_Salsano/
> 
>
> E-mail  : stefano.sals...@uniroma2.it
> Cell.   : +39 320 4307310
> Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
> ***
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> 
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] FW: IPR Poll for draft-filsfils-spring-srv6-network-programming

[bruno.decraene]

From: Milad Sharif [mailto:msha...@barefootnetworks.com]
Sent: Wednesday, April 10, 2019 5:44 PM
To: Dirk Steinberg
Cc: DECRAENE Bruno TGI/OLN; wim.henderi...@nokia.com; smy...@innovium.com; 
ar...@arista.com; hani.elma...@gmail.com; mashao...@gmail.com; 
p...@barefootnetworks.com; spring-cha...@ietf.org; 
draft-filsfils-spring-srv6-network-programm...@ietf.org
Subject: Re: IPR Poll for draft-filsfils-spring-srv6-network-programming

Hi,

I’m not aware of non-disclosed IPR.

Thanks,
Milad


On Wed, Apr 10, 2019, 3:14 AM Dirk Steinberg 
mailto:d...@lapishills.com>> wrote:
Hi Bruno,

I am not aware of any IPR regarding this draft.

Best
Dirk


mailto:bruno.decra...@orange.com>> schrieb am Mi., 
10. Apr. 2019, 10:01:
Hi,

If I’m not mistaken, you are a contributor to this IETF draft and you have not 
responded to the IPR call.
Could you please reply to the enclosed email, keeping everyone in copy of the 
email?

Thank you,
Regards,
--Bruno


From: DECRAENE Bruno TGI/OLN
Sent: Thursday, April 4, 2019 3:05 PM
To: DECRAENE Bruno TGI/OLN
Subject: RE: IPR Poll for draft-filsfils-spring-srv6-network-programming

Hi,

If I’m not mistaken, you are a contributor to this IETF draft and you have not 
responded to the IPR call.
Could you please reply to the enclosed email, keeping everyone in copy of the 
email?

Thank you,
Regards,
--Bruno

From: spring [mailto:spring-boun...@ietf.org] 
On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, March 13, 2019 7:50 PM
To: SPRING WG
Cc: 
draft-filsfils-spring-srv6-network-programm...@ietf.org
Subject: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming


Hi authors, SPRING WG,



In parallel to the call for adoption for 
draft-filsfils-spring-srv6-network-programming (1), we would like to poll for 
IPR.



If you are aware of IPR that applies to 
draft-filsfils-spring-srv6-network-programming please respond to this email.

If you are aware of IPR, please indicate whether it has been disclosed in 
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more 
details).



If you are an *author or contributor* please respond to this email regardless 
of whether or not you're aware of any IPR.

If you are not an author or contributor, please explicitly respond only if you 
are aware of IPR that has not yet been disclosed.



This document will not advance into the working group until IPR confirmations 
have been received from all authors and contributors.



Thank you,



(1) 
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07





--Bruno & Rob.


_



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.

_



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.



-- Forwarded message --
From: mailto:bruno.decra...@orange.com>>
To: SPRING WG mailto:spring@ietf.org>>
Cc: 
"draft-filsfils-spring-srv6-network-programm...@ietf.org"
 

[spring] IPR Poll for draft-filsfils-spring-srv6-network-programming

[Arthi Ayyangar]

Sorry for the delay.

I am not aware of any IPRs on this.


thanks,

Arthi


*From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *
bruno.decra...@orange.com
*Sent:* Wednesday, March 13, 2019 7:50 PM
*To:* SPRING WG
*Cc:* draft-filsfils-spring-srv6-network-programm...@ietf.org
*Subject:* [spring] IPR Poll for
draft-filsfils-spring-srv6-network-programming



Hi authors, SPRING WG,



In parallel to the call for adoption for
draft-filsfils-spring-srv6-network-programming (1), we would like to
poll for IPR.



If you are aware of IPR that applies to
draft-filsfils-spring-srv6-network-programming please respond to this
email.

If you are aware of IPR, please indicate whether it has been disclosed
in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378
provide more details).



If you are an *author or contributor* please respond to this email
regardless of whether or not you're aware of any IPR.

If you are not an author or contributor, please explicitly respond
only if you are aware of IPR that has not yet been disclosed.



This document will not advance into the working group until IPR
confirmations have been received from all authors and contributors.



Thank you,



(1)  
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07





--Bruno & Rob.



_



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.

_

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.




-- Forwarded message --
From: 
To: SPRING WG 
Cc: "draft-filsfils-spring-srv6-network-programm...@ietf.org" <
draft-filsfils-spring-srv6-network-programm...@ietf.org>
Bcc:
Date: Wed, 13 Mar 2019 18:50:00 +
Subject: [spring] IPR Poll for
draft-filsfils-spring-srv6-network-programming

Hi authors, SPRING WG,



In parallel to the call for adoption for
draft-filsfils-spring-srv6-network-programming (1), we would like to
poll for IPR.



If you are aware of IPR that applies to
draft-filsfils-spring-srv6-network-programming please respond to this
email.

If you are aware of IPR, please indicate whether it has been disclosed
in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378
provide more details).



If you are an *author or contributor* please respond to this email
regardless of whether or not you're aware of any IPR.

If you are not an author or contributor, please explicitly respond
only if you are aware of IPR that has not yet been disclosed.



This document will not advance into the working group until IPR
confirmations have been received from all authors and contributors.



Thank you,



(1)  
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07





--Bruno & Rob.



_

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 

[spring] IPR Disclosure Ciena Corporation s Statement about IPR related to draft-cheng-spring-mpls-path-segment

[IETF Secretariat]

Dear Weiqiang Cheng, Lei Wang, Han Li, Mach Chen, Rakesh Gandhi, Royi Zigler, 
Shuangping Zhan:


An IPR disclosure that pertains to your Internet-Draft entitled Path
Segment in MPLS Based Segment Routing Network
(draft-cheng-spring-mpls-path-segment) was submitted to the IETF Secretariat
on  and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/3492/). The title of the IPR
disclosure is "Ciena Corporations Statement about IPR related to
draft-cheng-spring-mpls-path-segment"


Thank you

IETF Secretariat

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

[spring] Éric Vyncke's No Objection on draft-ietf-spring-segment-routing-mpls-19: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: 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-spring-segment-routing-mpls/



--
COMMENT:
--

It is time to publish this one.

Nits


In section 2, "The flooding mechanisms of link state IGPs fits very well with
label stacking on ingress" while I do not disagree with the statement, it is
somehow out of the blue: either explain shortly why or delete the sentence if
so obvious. Note: or even keep it like it is now.

Section 2.5.1, binary numbers 100 and 110 should probably explicitly qualified
as binary representations.

Some typos in name or spacing in sections 6 and 7


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

Re: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming

[Voyer, Daniel]

As a co-author, I am not aware of any IPR other than the one already disclosed.
dan

From: spring  on behalf of Bruno Decraene 

Date: Wednesday, March 13, 2019 at 2:50 PM
To: SPRING WG 
Cc: "draft-filsfils-spring-srv6-network-programm...@ietf.org" 

Subject: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming


Hi authors, SPRING WG,



In parallel to the call for adoption for 
draft-filsfils-spring-srv6-network-programming (1), we would like to poll for 
IPR.



If you are aware of IPR that applies to 
draft-filsfils-spring-srv6-network-programming please respond to this email.

If you are aware of IPR, please indicate whether it has been disclosed in 
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more 
details).



If you are an *author or contributor* please respond to this email regardless 
of whether or not you're aware of any IPR.

If you are not an author or contributor, please explicitly respond only if you 
are aware of IPR that has not yet been disclosed.



This document will not advance into the working group until IPR confirmations 
have been received from all authors and contributors.



Thank you,



(1)  
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07





--Bruno & Rob.


_



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

Re: [spring] 答复: SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp

[Loa Andersson]

Quan,


I think you are right that this discussion will be of interest
for the SPRING and MPLS working group.

I have copied the working group mailing lists.

On 2019-04-10 09:47, xiong.q...@zte.com.cn wrote:


Hi Loa,


Thanks for your review and inspired comment! It is very important and 
much appreciated.



Refer to your question, we proposed the terminology of the "SR-MPLS-TP" 
in the following use case draft.


https://datatracker.ietf.org/doc/draft-hu-mpls-sr-inter-domain-use-cases/ 




We plan to work on the definition and scope of SR-MPLS-TP and start 
discussion in MPLS and SPRING working group next week.


Welcome to review and discuss about that draft and provide suggestions 
for SR-MPLS-TP!



Best Regards,

Quan



原始邮件
*发件人：*LoaAndersson 
*收件人：*p...@ietf.org 
;draft-xiong-pce-pcep-extension-sr...@ietf.org 
;

*日 期 ：*2019年04月10日 03:55
*主 题 ：**SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp*
Authors, Working Group,

MPLS-TP is defined as a network that:

    "It MUST be possible to operate and configure the MPLS-TP data
 plane without any IP forwarding capability in the MPLS-TP data
 plane. (RFC 5654, section 2.3, requirement 36.)"

 ...

   "It MUST be possible to provide protection for the MPLS-TP data
    plane without any IP forwarding capability in the MPLS-TP data
    plane. (RFC 5654, section 2.5.1.1, requirement 63.)"

In fact most MPLS-TP networks are deployed without IP in the data
plane.

SR-MPLS on the other hand is a technology that is defined to USE
IGPs to distribute MPLS-labels, and thus requires IP in the data
plane.

PCEP also runs over TCP/IP.

The draft does not discuss this. I think this is needed, do you
have plans to do so?

/Loa
--


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64




--


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64

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

[spring] FW: IPR Poll for draft-filsfils-spring-srv6-network-programming

[bruno.decraene]

From: Dirk Steinberg [mailto:d...@lapishills.com]
Sent: Wednesday, April 10, 2019 10:14 AM
To: DECRAENE Bruno TGI/OLN
Cc: wim.henderi...@nokia.com; smy...@innovium.com; ar...@arista.com; 
hani.elma...@gmail.com; mashao...@gmail.com; msha...@barefootnetworks.com; 
p...@barefootnetworks.com; spring-cha...@ietf.org; 
draft-filsfils-spring-srv6-network-programm...@ietf.org; Dirk Steinberg
Subject: Re: IPR Poll for draft-filsfils-spring-srv6-network-programming

Hi Bruno,

I am not aware of any IPR regarding this draft.

Best
Dirk


mailto:bruno.decra...@orange.com>> schrieb am Mi., 
10. Apr. 2019, 10:01:
Hi,

If I’m not mistaken, you are a contributor to this IETF draft and you have not 
responded to the IPR call.
Could you please reply to the enclosed email, keeping everyone in copy of the 
email?

Thank you,
Regards,
--Bruno


From: DECRAENE Bruno TGI/OLN
Sent: Thursday, April 4, 2019 3:05 PM
To: DECRAENE Bruno TGI/OLN
Subject: RE: IPR Poll for draft-filsfils-spring-srv6-network-programming

Hi,

If I’m not mistaken, you are a contributor to this IETF draft and you have not 
responded to the IPR call.
Could you please reply to the enclosed email, keeping everyone in copy of the 
email?

Thank you,
Regards,
--Bruno

From: spring [mailto:spring-boun...@ietf.org] 
On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, March 13, 2019 7:50 PM
To: SPRING WG
Cc: 
draft-filsfils-spring-srv6-network-programm...@ietf.org
Subject: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming


Hi authors, SPRING WG,



In parallel to the call for adoption for 
draft-filsfils-spring-srv6-network-programming (1), we would like to poll for 
IPR.



If you are aware of IPR that applies to 
draft-filsfils-spring-srv6-network-programming please respond to this email.

If you are aware of IPR, please indicate whether it has been disclosed in 
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more 
details).



If you are an *author or contributor* please respond to this email regardless 
of whether or not you're aware of any IPR.

If you are not an author or contributor, please explicitly respond only if you 
are aware of IPR that has not yet been disclosed.



This document will not advance into the working group until IPR confirmations 
have been received from all authors and contributors.



Thank you,



(1) 
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07





--Bruno & Rob.


_



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.

_



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.



-- Forwarded message --
From: mailto:bruno.decra...@orange.com>>
To: SPRING WG mailto:spring@ietf.org>>
Cc: 
"draft-filsfils-spring-srv6-network-programm...@ietf.org"
 
mailto:draft-filsfils-spring-srv6-network-programm...@ietf.org>>
Bcc:
Date: Wed, 13 Mar 2019 18:50:00 +
Subject: [spring] IPR Poll 

Re: [spring] Deborah Brungard's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

[Vigoureux, Martin (Nokia - FR/Paris-Saclay)]

Hello Deborah,

thanks for your review.
Regarding your discuss, Sasha had said:
I see two possibilities to resolve this controversy: either make the 
check in question a “real requirement” (i.e., replace MAY with SHOULD or 
even MUST) or explain why it is safe ...
Sasha was thus proposing s/MAY/SHOULD/ or s/MAY/MUST/ as the first option.

The authors have followed Sasha suggestion. The text now reads:

An implementation SHOULD check that an IGP node-SID is not associated

-m

Le 2019-04-09 à 23:09, Deborah Brungard via Datatracker a écrit :
> Deborah Brungard has entered the following ballot position for
> draft-ietf-spring-segment-routing-mpls-19: Discuss
> 
> 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-spring-segment-routing-mpls/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> I didn't see a fix/response to one of Sasha's identified items in his RTG Dir
> review:
> 
> - 1.The text in Section 1 states “An implementation MAY
> check that an IGP node-SID is not associated with a prefix that is owned by
> more than one router within the same routing domain, If so, it SHOULD NOT use
> this Node-SID, MAY use another one if available, and SHOULD log an error”.
> 
> Sasha suggested MAY/s/SHOULD or MUST,  saying this aligns with Section
> 3.2/RFC8402, which uses the wording "MUST NOT" be used by another router.
> 
> I agree with Sasha, to align, it would be a "MUST", so why the softer
> requirement? Also, how does an implementation "check"? Wouldn't it be simply
> "An implementation MUST ensure that an.."? Or the operator (NMS) needs to
> ensure (e.g. RFC8402 says typically allocated by policy of the operator)?
> 
> 
> --
> COMMENT:
> --
> 
> Noting Mirja's comment asking why is this not Informational, I agree with the
> current track as "PS" as it does define (using RFC2119 keywords) procedures
> (labels).
> 
> Nit: Section 2
> I had difficulty parsing the first bullet:
>>From a control plane perspective, [RFC3031] does not mandate a single 
>>signaling
> protocol.  Segment Routing makes use of various control plane protocols such 
> as
> link state IGPs [I-D.ietf-isis-segment-routing-extensions],
> [I-D.ietf-ospf-segment-routing-extensions] and
> [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding mechanisms of
> link state IGPs fits very well with label stacking on ingress. Future control
> layer protocol and/or policy/configuration can be used to specify the label
> stack. /suggest/ From a control plane perspective, [RFC3031] does not mandate 
> a
> single control protocol or use of a control protocol. Segment Routing makes 
> use
> of various control plane protocols such as link state IGPs
> [I-D.ietf-isis-segment-routing-extensions],
> [I-D.ietf-ospf-segment-routing-extensions] and
> [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding mechanisms of
> link state IGPs fits very well with label stacking on ingress. Future control
> layer protocols are not precluded and/or management policy/configuration can 
> be
> used to specify the label stack.
> 
> 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring