Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

[Acee Lindem (acee)]

Hi Suresh, Adrian,

From: spring  on behalf of Suresh Krishnan 

Date: Sunday, September 25, 2022 at 11:17 PM
To: Adrian Farrel 
Cc: Jen Linkova , 6man , "spring@ietf.org" 
, 6man Chairs <6man-cha...@ietf.org>, 
"draft-ietf-6man-sids.auth...@ietf.org" 
, "spring-cha...@ietf.org" 

Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Hi Adrian,
  Thanks for your comments. Greatly appreciate your detailed review. Please 
find responses inline.

On Sep 24, 2022, at 1:13 PM, Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:

Hi Jen, all,

I've done a review of this document as part of working group last call.
I found quite a few nits and so on, so I think the document needs some
more work before escaping from the working group and being present for
publication.

Cheers,
Adrian

==

I find it odd that this is an Informational document but its use of
BCP14 language appears to constrain and direct implementations. So
either you need to drop down to normal lowercase usage, or change the
document to Standards Track.

There is only one use (a MUST in Section 3) that could easily be
resolved.

I have a text resolution that removes this as a response to one of your other 
points below.



---

Section headers need to be in header case

OK.



---

You seem to freely interchange "Segment List" and "SID list". It would
help to pick a term and stick with it since the change suggests there
is a difference in meaning. If you are happy that they are the same, you
could:
- fix the text to use one term consistently
- mention that the terms are equivalent in Section 2

The SID list terminology is something that is used in the spring compression 
design team document (draft-ietf-spring-compression-analysis) and I had to use 
it to refer to the document. I think we should stick with Segment list.



---

Please select "Destination Address" or "destination address field" or
"Destination address field" or "Destination address" and use it
consistently.

OK.



---

Abstract

No citations in the Abstract

This document "intends"? Probably just state that it does.

OK.



---

Section 3

  From this it
  follows that all the SIDs that appear in the SRH are not SRv6 SIDs as
  defined by [RFC8402].

I'm hoping you didn't intend what is written (because that would pretty
much mean that SRv6 is dead!). Perhaps...

  From this it
  follows that not all the SIDs that appear in the SRH are SRv6 SIDs as
  defined by [RFC8402].

Maybe, it is also better to keep the context of the Segment List which
is how you introduced these SIDs. Something like...

  From this it
  follows that not all the SIDs that appear in the SRH Segment List are
  SRv6 SIDs as defined by [RFC8402].

The previous sentence



sets the context for the sentence you quoted. I think your second suggestion 
sounds great and will remove any possibility that this sentence could be 
misread.




---

3.

"It is also fairly clear"
Well, that is illuminating :-)
Perhaps you want to make statements about the SID elements and not about
the clarity of the referenced documents?

Sure :-). Suggest

OLD:
   It is also fairly clear that the non-SRv6-SID elements that appear in
   the SRH SID list are simply IPv6 addresses assigned to local
   interfaces annd MUST conform to [RFC4291].

NEW:
   As stated above, the non-SRv6-SID elements that appear in
   the SRH SID list are simply IPv6 addresses assigned to local
   interfaces and they need to conform to [RFC4291].



---

3.

s/annd/and/

Ack.



---

3.

  the following
  discussions are intended to be applicable

Maybe s/are intended to be/are/

OK.



---

3.

  Section 3.1. of [RFC8986] describes the format of an SRv6 SID as
  composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is
  encoded in the L most significant bits of the SID, followed by F bits
  of function (FUNCT) and A bits of arguments (ARG).

Would it be helpful to qualify L+F+A = 128 in all cases?

Actually not. RFC8986 defines L+F+A <=128 instead and this would be 
inconsistent with that.



---

3.

  When an SRv6 SID occurs in the IPv6 destination address field of an
  IPv6 header, only the longest match prefix corresponding to the
  locator is used to forward the packet to the node identified by the
  Locator.

Possibly you mean s/is used/should be used/
Or maybe s/used/used by an SRv6-capable node/

This is written as a statement about what happens today rather than specifying 
behavior for the node to follow.



---

3.

  While looking at the transit nodes it becomes apparent that these
  addresses are used purely for routing and not for packet delivery to
  end hosts.

The distinction between "end host" and "destination" is a fine one. When
you are a transit node, you can't tell the difference. When the DA
identifies the end of a segment, it is (from a network point of view)
exactly like identifying an end host.

Maybe, in fact, you mean "packet delivery at end hosts" (at not to).

I think you should also be careful with the term "routing" as 

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

[Acee Lindem (acee)]

Hi Jen, Coauthors, et al, 

I have read this document and support publication. The document contains useful 
information and can hopefully be reference to avoid rehashing the relationship 
between IPv6 Addressing Architecture and SRv6 SIDs. I have two comments.

   1. Since this document has an IANA allocation, should it be Standards Track? 
   2. I think the Security Considerations should reference the discussion in 
section 5 regarding the scope of SRv6 SIDs. 

Thanks,
Acee

On 9/17/22, 4:02 AM, "spring on behalf of Jen Linkova" 
 wrote:

Hello,

This email starts the 6man Working Group Last Call for the "Segment
Identifiers in SRv6" draft
(https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids).

The WGLC ends on Tue, Oct 4, 23:59:59 UTC.

 As the document is closely related to the work in the SPRING WG, we'd
like the SPRING WG to review the document and discuss the following
questions:

- the action items required from SPRING (Section 4.1 and 4.2 of the
draft, 
https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4)
[*]. Would it make sense to merge those open issues with the 'Open
Issues' section of
the SPRING document?
-  whether the document needs more guidance regarding routability of
/16 or such requirements shall belong to some other document?  In
particular,  shall we specify that it MUST NOT be in the DFZ? Or
setting 'Globally Reachable = false' in the registry should be
sufficient? The current idea is that the prefix needs to fail closed
and not be routable by default.

[*] The draft currently refers to the individual submission instead of
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
 - the link will be updated in the next revision.

Please review the draft and send your comments to the list/

-- 
SY, Jen Linkova aka Furry

___
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: IETF WG state changed for draft-ietf-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

SPRING WG, 

Note that we have completed WG last call on the subject document. This draft 
provides the OSPFv3 extensions analogous to the IS-IS SRv6 extensions 
That are already on the RFC Queue 
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Thanks, 
Acee, LSR Co-Chair 

On 8/30/22, 10:48 AM, "IETF Secretariat"  
wrote:


The IETF WG state of draft-ietf-lsr-ospfv3-srv6-extensions has been changed
to "WG Consensus: Waiting for Write-Up" from "In WG Last Call" by Acee 
Lindem:

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/



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

Re: [spring] Proposed policy on reporting implementation and interoperability

[Acee Lindem (acee)]

I agree – it’s great to document the implementations but let’s not require 
every line of the drafts to implemented prior to publication.

Thanks,
Acee



From: spring  on behalf of Tony Przygienda 

Date: Friday, August 12, 2022 at 11:05 AM
To: "Eric Vyncke (evyncke)" 
Cc: John Scudder , "spring@ietf.org" , 
Alvaro Retana , Andrew Alston 

Subject: Re: [spring] Proposed policy on reporting implementation and 
interoperability



On Thu, Aug 11, 2022 at 3:58 PM Eric Vyncke (evyncke) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Bruno, Jim, Joel,

Without any hat, or only with the experience of reviewing so many I-Ds from 
different areas and having implemented a couple of proof-of-concept 
implementations of various IETF drafts.

The following are just comments for discussion, not criticisms because indeed 
running code is important at the IETF.

RFC 7942, an IETF stream BCP (i.e., with IETF consensus), is already useful but 
*optional* while the proposal below would be mandatory. Hence, I share Dhruv’s 
question: will it also apply to experimental or informational documents or BCP? 
Joel, thank you for your reply to Dhruv, it seems a sensible solution.

You may be aware of a long-standing project/idea/wish of the IESG to have a 
*living document concept* that could be updated for years after RFC 
publication. As you can imagine there are too many gears to make fast progress 
on this topic, but the current proposal is to move the ‘living’ part of the doc 
to a github repo under the IETF organization (e.g., done in MOPS). Wouldn’t it 
be a better fit than a section ‘carved in stone’ forever (even if time-stamped) 
in an RFC?

Getting an implementation could sometimes be easy in Python or Go in Linux at a 
hackathon  ;-), or in “slow path”, a little more complex in P4, even more in 
silicon... the ultimate step is of course a *deployment* outside of a 
virtualized lab:, i.e., in a production network. Of course, deployment (and 
interoperation) in a production network is the Graal ;-) But, where to put a 
useful but realistic needle *without delaying* the standardization process ?

Getting things deployed is a monumentous task mostly, often deployment happens 
based on RFI/RFPs using RFCs (seldom based on drafts IME since those are moving 
targets). And normally, it's not RFCs being published as deployment 
documentation (though it happens, e.g. VxLAN).  So, good potential for an 
unresolvable dependency circle if deployment documentation has any influence on 
RFC status.

-- tony

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

Re: [spring] IETF 114 MeetEcho Room Closed

[Acee Lindem (acee)]

I just got a ping that it is up on WebEx Teams… I’ll try again.

From: Ketan Talaulikar 
Date: Wednesday, July 27, 2022 at 10:12 AM
To: Acee Lindem 
Cc: SPRING WG 
Subject: Re: [spring] IETF 114 MeetEcho Room Closed

There is some issue with meetecho it seems.

I hope someone from the room will let us know once they get it sorted out.

Thanks,
Ketan


On Wed, 27 Jul, 2022, 7:38 pm Acee Lindem (acee), 
mailto:40cisco@dmarc.ietf.org>> wrote:
Am I the only one getting this?

[cid:image001.png@01D8A1A0.BFB6B0D0]
___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Re： MSR6 side meeting at IETF 112

[Acee Lindem (acee)]

It appears that it overlaps the Routing Area Open Meeting… Am I missing 
something?

From: spring  on behalf of Yisong Liu 

Date: Thursday, November 11, 2021 at 7:02 AM
To: spring 
Cc: chengweiqiang , "Gengxuesong (Geng Xuesong)" 
, Michael McBride , 
Robin Li 
Subject: [spring] Re： MSR6 side meeting at IETF 112

Hi SPRING,

As a reminder, we will have an MSR6(Multicast Segment Routing over IPv6) side 
meeting on Friday. Please find the .ics file in the attachment and the webex 
link is :
https://htf-paris.my.webex.com/wbxmjs/joinservice/sites/htf-paris.my-en/meeting/download/e1f15a5546aa4426bbee2b128f13bfca?siteurl=htf-paris.my-en=m640f36efb4135d33151f488d1b7ba206
Welcome to join!

Best Regards
Yisong

发件人: Yisong Liu
时间: 2021/11/08(星期一)17:27
收件人: spring;
抄送人: chengweiqiang;Michael 
McBride;Lizhenbin;Gengxuesong
 (Geng Xuesong);
主题: MSR6 side meeting at IETF 112
Hi WG,

We will have a side meeting to discuss Multicast Segment Routing over 
IPv6(MSR6) on Friday 13:00-14:30 UTC.
Agenda, related documents and other information of the side meeting could be 
found:https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings .
Welcome to join the discussion!

Best Regards
Yisong


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

Re: [spring] SRv6 SID List compression

[Acee Lindem (acee)]

Speaking as a WG chair from another WG:

If you followed the SPRING debate preceding the formation of the DT, it was 
obvious that allowing open membership to the DT would not have been feasible 
given the number of people participating and the combative tone of the 
discussion. I think the chairs did an excellent job of selecting and chartering 
the design team.

Thanks,
Acee

From: spring  on behalf of James Guichard 

Date: Wednesday, July 28, 2021 at 9:34 AM
To: Robert Raszuk , Wim Henderickx 
Cc: Ron Bonica , SPRING WG 
, "Darren Dukes (ddukes)" 
Subject: Re: [spring] SRv6 SID List compression

Hi Robert,

In short the answer to your question is no.  The chairs tried to create an 
inclusive DT that had representation from all sides of the compression debate. 
In addition the chairs deliberately stepped back and did not interfere in the 
DT work.

Jim, Joel & Bruno

From: spring  On Behalf Of Robert Raszuk
Sent: Tuesday, July 27, 2021 7:49 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) 
Cc: Ron Bonica ; SPRING WG 
; Darren Dukes (ddukes) 
Subject: Re: [spring] SRv6 SID List compression


On the composition of the DT, the selection was done by the WG, so are we 
questioning if this was done appropriately. People have various backgrounds and 
I found the mix pretty good. Again if after 1 year this is being discussed I 
find this very odd. Could have been done a while ago if there were concerns.

Was there anyone denied by the SPRING chairs to join this DT ?

If yes - let's hear from the chairs why.

If not - the point is moot.

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

Re: [spring] Roman Danyliw's Discuss on draft-ietf-spring-sr-yang-29: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Roman,

Please see inline. 


On 1/20/21, 10:13 PM, "Roman Danyliw via Datatracker"  wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-spring-sr-yang-29: 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-sr-yang/



--
DISCUSS:
--

Section 9.  The primary impact of the manipulating writable nodes appears 
to be
characterized as DoS.  Don’t the possible consequences also include the 
ability
to leak traffic outside the trusted domain or to route traffic through
arbitrary paths of the attackers choosing potentially enable on-path 
inspection
or manipulation of traffic; or avoidance of security controls?

We have revised the writable nodes in the -30 version:

  /segment-routing/mpls/bindings - Modification to the local
  bindings could result in a Denial of Service (DoS) attack.  An
  attacker may also try to create segment conflicts (using the same
  segment identifier for different purposes) to redirect traffic
  within the trusted domain.  However, the traffic will remain
  within the trusted domain.  Redirection could be used to route the
  traffic to compromised nodes within the trusted domain or to avoid
  certain security functions (e.g., firewall).  Refer to section 8.1
  [RFC8402] for a discussion of the SR-MPLS trusted domain.

  /segment-routing/mpls/srgb - Modification of the Segment Routing
  Global Block (SRGB) could be used to mount a DoS attack.  For 

  example, if the SRGB size is reduced to a very small value, a lot
  of existing segments could no longer be installed leading to a
  traffic disruption.

  /segment-routing/mpls/srlb - Modification of the Segment Routing
  Local Block (SRLB) could be used to mount a DoS attacks similar to
  those applicable to the SRGB.

  /segment-routing/mpls/label-blocks - Modification of the Segment
  Routing label blocks could be used to mount a DoS attack.


--
COMMENT:
--

** Section 9.  Thanks for using the templated YANG Security Considerations. 
 A
nit on the references s/[RFC6536]/[RFC8341]/

** Section 9.  The following caution around readable nodes didn’t parse for 
me.
 Was the intent as follows:

OLD
The exposure of both local
   bindings and SID database will exposure segment routing paths that
   may be attacked.

NEW
The exposure of either the local bindings or SID database would provide an
attacker the segment routing paths and related topology information.

** Section 9.  Typo. s/a a/a/

** Section 9.  Typo. s/rediection/redirection/

We've incorporated all your comments into the -30 version. 

Thanks,
Acee




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

Re: [spring] Benjamin Kaduk's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)

[Acee Lindem (acee)]

Hi Ben, 
See one inline.

On 1/21/21, 5:42 PM, "Benjamin Kaduk"  wrote:

Hi Acee,

On Thu, Jan 21, 2021 at 10:19:35PM +0000, Acee Lindem (acee) wrote:
> Hi Ben, 
> Thanks for your review. 
> 
> On 1/21/21, 4:08 AM, "Benjamin Kaduk via Datatracker"  
wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-spring-sr-yang-29: 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-sr-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> If "srgb" already stands for "segment routing global block", what does
> the extra "global" in "global-srgb" mean?
> 
> I agree that it is redundant. 
> 
> I support Roman's Discuss.
> 
> Section 4
> 
>The module ietf-segment-routing-mpls augments the "/rt:routing/
>sr:segment-routing:" with a sr-mpls container.  This container
>defines all the configuration parameters related to segment-routing
>MPLS data plane.
> 
> nit: missing "the" ("the segment-routing MPLS data plane").
> 
> Fixed in a couple places. 
> 
>   *  Connected prefixes : maps connected prefixes to a segment ID.
>  Advertisement of the mapping will be done by IGP when enabled
>  for segment routing (see Section 5).  The SID value can be
>  expressed as an index (default), or an absolute value.  The
>  "last-hop-behavior" configuration dictates the PHP behavior:
>  "explicit-null", "php", or "non-php".
> 
> Is the penultimate hop here a SR hop (a la PSP) or an underlying 
routing
> protocol hop?
> 
> It is the routing next-hop for MPLS PHP but that router would support SR. 
I'll add "MPLS" to the text. 

Thanks!  That was my suspicion, but it seems helpful to remove the
potential confusion.

> Section 5.1.1.1
> 
>(i.e., a bundle of adjacencies).  The "advertise-adj-group-sid"
>configuration controls whether or not an additional adjacency SID 
is
>advertised.
> 
> nit: I think it is better to say "controls for which group(s) an
> additional adjacency SID is advertised" -- the current wording implies
> that there would only be one additional SID, but IIUC it is one
> additional SID per group.
> 
> Agreed. Fixed. 
> 
>both interfaces L3 and L4.  This will result in R1 advertising an
>additional Adj-SID for each adjacency, for example a Adj-SID with S
>flag set and value of 400 will be added to L1 and L2.  A Adj-SID 
with
>S flag set and value of 500 will be added to L3 and L4.  As L1/L2 
and
>L3/L4 does not share the same "group-id", a different SID value 
will
>be allocated.
> 
> I don't think I remember where the 'S flag' is specified (or the
> 'B-flag' in the following section).  This is still in the
> protocol-independent part of the model/document, right?  (Also, nit,
> please consistently hyphenate or don't hyphenate the "X flag"
> construction.)
> 
> I agree that S-flag is an IGP encoding and need not be included in the 
example since it isn't discussed elsewhere. 
> 
> Section 8.2
> 
>  grouping prefix-sid {
>description
>  "This grouping defines cfg of prefix SID.";
> 
> nit: I think we can write out "config" or even "configuration" here.
> Fixed. 
> 
> Section 8.3
> 
>  feature max-sid-depth {
>description
>  "Support for signaling MSD (Maximum SID Depth) in IGP.";
>   

Re: [spring] Benjamin Kaduk's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)

[Acee Lindem (acee)]

Hi Ben, 
Thanks for your review. 

On 1/21/21, 4:08 AM, "Benjamin Kaduk via Datatracker"  wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-spring-sr-yang-29: 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-sr-yang/



--
COMMENT:
--

If "srgb" already stands for "segment routing global block", what does
the extra "global" in "global-srgb" mean?

I agree that it is redundant. 

I support Roman's Discuss.

Section 4

   The module ietf-segment-routing-mpls augments the "/rt:routing/
   sr:segment-routing:" with a sr-mpls container.  This container
   defines all the configuration parameters related to segment-routing
   MPLS data plane.

nit: missing "the" ("the segment-routing MPLS data plane").

Fixed in a couple places. 

  *  Connected prefixes : maps connected prefixes to a segment ID.
 Advertisement of the mapping will be done by IGP when enabled
 for segment routing (see Section 5).  The SID value can be
 expressed as an index (default), or an absolute value.  The
 "last-hop-behavior" configuration dictates the PHP behavior:
 "explicit-null", "php", or "non-php".

Is the penultimate hop here a SR hop (a la PSP) or an underlying routing
protocol hop?

It is the routing next-hop for MPLS PHP but that router would support SR. I'll 
add "MPLS" to the text. 

Section 5.1.1.1

   (i.e., a bundle of adjacencies).  The "advertise-adj-group-sid"
   configuration controls whether or not an additional adjacency SID is
   advertised.

nit: I think it is better to say "controls for which group(s) an
additional adjacency SID is advertised" -- the current wording implies
that there would only be one additional SID, but IIUC it is one
additional SID per group.

Agreed. Fixed. 

   both interfaces L3 and L4.  This will result in R1 advertising an
   additional Adj-SID for each adjacency, for example a Adj-SID with S
   flag set and value of 400 will be added to L1 and L2.  A Adj-SID with
   S flag set and value of 500 will be added to L3 and L4.  As L1/L2 and
   L3/L4 does not share the same "group-id", a different SID value will
   be allocated.

I don't think I remember where the 'S flag' is specified (or the
'B-flag' in the following section).  This is still in the
protocol-independent part of the model/document, right?  (Also, nit,
please consistently hyphenate or don't hyphenate the "X flag"
construction.)

I agree that S-flag is an IGP encoding and need not be included in the example 
since it isn't discussed elsewhere. 

Section 8.2

 grouping prefix-sid {
   description
 "This grouping defines cfg of prefix SID.";

nit: I think we can write out "config" or even "configuration" here.
Fixed. 

Section 8.3

 feature max-sid-depth {
   description
 "Support for signaling MSD (Maximum SID Depth) in IGP.";
 reference "RFC 8476: Signaling Maximum SID Depth (MSD)
  Using OSPF
RFC 8491: Signaling Maximum SID Depth (MSD)
  Using IS-IS
RFC 8814: Singaling Maximum SID Deppt (MSD)
  Using the Border Gateway Protocol
  (BGP) - Link State";
 }

I feel like a few more words are in order -- do I claim the feature if I
inplement only one IGP's signaling?  Or do I need to have all three?  Or
"just" have support for it in all the IGPs that I support?

Agreed. I'll make it at least one protocol.

   enum "dual" {
 description
   "Two Adj-SIDs will be associated with the adjacency
if the interface is protected. In this case, will
be advertised with backup flag set, the other will
be advertised with the backup flag clear. In case
protection is not configured, single Adj-SID will
be advertised with the backup flag clear.";

nit: some missing words, maybe "In this case, one will", ", and the
other will", "a single Adj-SID will".

Fixed. 

 description
   "Node MSD is 

Re: [spring] Éric Vyncke's Abstain on draft-ietf-spring-sr-yang-29: (with COMMENT)

[Acee Lindem (acee)]

HI Eric, 

See inline.

On 1/14/21, 8:46 AM, "Éric Vyncke via Datatracker"  wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-spring-sr-yang-29: Abstain

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-sr-yang/



--
COMMENT:
--

Thank you for the work put into this document even if I am balloting 
ABSTAIN,
this is useful piece and it should really be improved to fix my ABSTAIN 
reasons
so that I could actively support it. Read my ABSTAIN ballot as "I oppose 
this
document but understand that others differ and am not going to stand in the 
way
of the others" per https://www.ietf.org/standards/process/iesg-ballots/ .

Please note that I am neither a YANG expert nor a segment routing one 
(hence my
ABSTAIN rather than a DISCUSS).

Based on title, I was expecting this document to be generic and to see
companion YANG models for the MPLS and IPv6 data planes but it seems that 
this
document also augments *only* the MPLS one. The asymmetry does not look 
good to
me... Are the authors/WG sure that the IPv6 YANG model can also be 
specified by
augmenting this model (draft-ietf-spring-srv6-yang-00 is still a -00 ...) 
and
relying on types defined in ietf-segment-routing-common ? Especially when
noting that the authors are different ?

Yingzhen and I have had several meetings with the SRv6 YANG model editors and 
are confident that there is alignment. 

The YANG model for SR is really short (mostly meaningless except for one 
more
tag in the namespace tree):
   "module: ietf-segment-routing
 augment /rt:routing:
   +--rw segment-routing"

To be honest, I strongly dislike the fact that there is no common element
between the YANG modules for MPLS and IPv6 data planes inside
ietf-segment-routing. I admit that I am not an SR expert but I would have
expected more common elements: policies, routing protocols, SID, link 
bundles,

There are many ways to factor the IETF YANG models and this one includes the 
base segment routing support. It seems you are not in touch with the other 
routing and segment routing models. For example, the routing protocol segment 
routing extensions are augmentations to the routing protocol models (in 
alignment with the vendor implementations). 

Thanks,
Acee


... even if the leaves could be instantiated as generic types to be 
augmented
later.

One additional regret is that the document shepherd write-up is really 
really
short. But it includes the most important element (to my eyes): the WG 
feedback
& consensus.

Regards,

-éric




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

Re: [spring] I-D Action: draft-ietf-spring-sr-yang-28.txt

[Acee Lindem (acee)]

After some discussion with Stephane, we decided the Maximum Segment Depth (MSD) 
is a property of the underlying hardware and should not be configurable. Please 
comment on this change. That is the only change in the -28 version. 
Thanks,
Acee

On 11/28/20, 12:19 PM, "spring on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Source Packet Routing in Networking WG of 
the IETF.

Title   : YANG Data Model for Segment Routing
Authors : Stephane Litkowski
  Yingzhen Qu
  Acee Lindem
  Pushpasis Sarkar
  Jeff Tantsura
Filename: draft-ietf-spring-sr-yang-28.txt
Pages   : 40
Date: 2020-11-28

Abstract:
   This document defines a YANG data model for segment routing
   configuration and operation, which is to be augmented by different
   segment routing data planes.  The document also defines a YANG model
   that is intended to be used on network elements to configure or
   operate segment routing MPLS data plane, as well as some generic
   containers to be reused by IGP protocol modules to support segment
   routing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-sr-yang-28
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-28

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-28


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/


___
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

Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard

[Acee Lindem (acee)]

Hi Tom 
Please see the -27 version. I believe it addresses your concerns as well as 
changing "http:" to "https:". 
Thanks,
Acee

On 11/26/20, 5:43 AM, "tom petch"  wrote:

I have looked at -26 and it looks good apart from BGP.

BGP gets a mention in passing but does not get the same treatment as the 
protocols of the LSR WG.  I am unclear whether or not this I-D is 
intended to include networks using BGP or not with e.g. signalling of 
MSD and would value a clarification in the I-D.

I wonder about the final D in
Maximum SID Depth (MSD)D
in the YANG; I suspect that it is spurious.

Tom Petch

On 24/11/2020 09:34, tom petch wrote:
    > On 23/11/2020 17:27, Acee Lindem (acee) wrote:
>> Hi Tom,
>>
>> See a couple responses inline enclosed in  and . We are
>> addressing the rest of your comments.
>>
>> On 11/18/20, 7:39 AM, "tom petch"  wrote:
>>
>>  IANA Considerations does not register the module names used in
>> the modules
>>
>> 
>> This is in the IANA considerations...
>
> 
> Indeed; I do not see a registration of ietf-segment-routing-mpls!
>
>> This document registers a YANG module in the YANG Module Names
>> registry [RFC6020].
>>
>>name: ietf-segment-routing-common
>>namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common
>>prefix: sr-cmn
>>reference: RFC 
>>
>>name: ietf-segment-routing
>>namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing
>>prefix: sr
>>reference: RFC 
>>
>>name: ietf-segment-routing
>>namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
>>prefix: sr-mpls
>>reference: RFC 
>> 
>>
>>  Examples are IPv4 only, IPv6 would be good
>>
>>  BGP is included when it comes to defining a router-id but is ignored
>>  everywhere else, such as signalling MSD, protocol extensions etc
>>
>>  reference "RFC " would be improved by including the title in all
>>  cases not just some
>>
>>  the scheme http: appears in many places.  It would be lovely if this
>>  really was the scheme but I fear that it is not
>> 
>> This is directly from the RFC 8407 template in Appendix B. What would
>> you suggest?
>
> 
> Many I-D do now specify https: since that is now the only option
> supported by the IETF; I have seen this called for by an AD.
>
>
>> 
>>
>>  module srcmn
>>the upper bound must be larger
>>the value must be greater
>>  consistency is good - I think greater is better
>>
>>  8.3
>>  operation states
>>  usually operational
>>
>>  two imports lack references
>>
>>  typedef router-id
>>  this is a well known type from RFC8394; it seems likely to
>> confuse to
>>  redefine it with a related but different meaning
>>
>>  leaf enabled
>>  enables protocol extensions
>>  which protocols?
>>
>>  leaf protected
>>  it is used to protect
>>  how does it do that:-)
>>
>>  enum dual
>>  ... In this case will be advertised with backup flag set
>>  What is the backup flag?  It does not feature in RFC8660.  Needs an
>>  explanation and reference
>>
>>  container link-msd
>>list link-msds
>>  leaf msd
>>  The usual YANG convention is for a list to be plural and the leaf
>>  singular.  You have the plural list but not the leaf.
>> 
>> So you are asking for a change from "leaf msd" to "leaf link-msd"?
>
> 
> Yes I would especially given node-msd.  I wish that YANG Guidelines said
> more about container names.  I think that having the same identifier for
> container, for list, for leaf (which I have seen in another I-D)
> will lead to mistakes so having a convention for list and leaf will
> reduce mistakes but having another for container would be even better.
> That said, I have yet to think of a good convention
> In passing, must link-msd be >= node-msd?
>
&g

Re: [spring] I-D Action: draft-ietf-spring-sr-yang-26.txt

[Acee Lindem (acee)]

-25 addressed most of Tom Petch's comments and -26 updated the Security 
Considerations. 
Thanks,
Acee

On 11/25/20, 4:15 PM, "spring on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Source Packet Routing in Networking WG of 
the IETF.

Title   : YANG Data Model for Segment Routing
Authors : Stephane Litkowski
  Yingzhen Qu
  Acee Lindem
  Pushpasis Sarkar
  Jeff Tantsura
Filename: draft-ietf-spring-sr-yang-26.txt
Pages   : 39
Date: 2020-11-25

Abstract:
   This document defines a YANG data model for segment routing
   configuration and operation, which is to be augmented by different
   segment routing data planes.  The document also defines a YANG model
   that is intended to be used on network elements to configure or
   operate segment routing MPLS data plane, as well as some generic
   containers to be reused by IGP protocol modules to support segment
   routing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-sr-yang-26
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-26

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-26


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/


___
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

Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard

[Acee Lindem (acee)]

Hi Tom, 

On 11/24/20, 4:34 AM, "tom petch"  wrote:

On 23/11/2020 17:27, Acee Lindem (acee) wrote:
> Hi Tom,
>
> See a couple responses inline enclosed in  and . We are 
addressing the rest of your comments.
>
> On 11/18/20, 7:39 AM, "tom petch"  wrote:
>
>  IANA Considerations does not register the module names used in the 
modules
>
> 
> This is in the IANA considerations...


Indeed; I do not see a registration of ietf-segment-routing-mpls!

Yes - I see the typo now that you pointed out which one. 

> This document registers a YANG module in the YANG Module Names
> registry [RFC6020].
>
>name: ietf-segment-routing-common
>namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common
>prefix: sr-cmn
>reference: RFC 
>
>name: ietf-segment-routing
>namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing
>prefix: sr
>reference: RFC 
>
>name: ietf-segment-routing
>namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
>prefix: sr-mpls
>reference: RFC 
> 
>
>  Examples are IPv4 only, IPv6 would be good
>
>  BGP is included when it comes to defining a router-id but is ignored
>  everywhere else, such as signalling MSD, protocol extensions etc
>
>  reference "RFC " would be improved by including the title in all
>  cases not just some
>
>  the scheme http: appears in many places.  It would be lovely if this
>  really was the scheme but I fear that it is not
> 
> This is directly from the RFC 8407 template in Appendix B. What would you 
suggest?


Many I-D do now specify https: since that is now the only option 
supported by the IETF; I have seen this called for by an AD.

As long as the URLs work, I don't see a problem with either. 


> 
>
>  module srcmn
>the upper bound must be larger
>the value must be greater
>  consistency is good - I think greater is better
>
>  8.3
>  operation states
>  usually operational
>
>  two imports lack references
>
>  typedef router-id
>  this is a well known type from RFC8394; it seems likely to confuse to
>  redefine it with a related but different meaning
>
>  leaf enabled
>  enables protocol extensions
>  which protocols?
>
>  leaf protected
>  it is used to protect
>  how does it do that:-)
>
>  enum dual
>  ... In this case will be advertised with backup flag set
>  What is the backup flag?  It does not feature in RFC8660.  Needs an
>  explanation and reference
>
>  container link-msd
>list link-msds
>  leaf msd
>  The usual YANG convention is for a list to be plural and the leaf
>  singular.  You have the plural list but not the leaf.
> 
> So you are asking for a change from "leaf msd" to "leaf link-msd"?


Yes I would especially given node-msd.  I wish that YANG Guidelines said 
more about container names.  I think that having the same identifier for 
container, for list, for leaf (which I have seen in another I-D)
will lead to mistakes so having a convention for list and leaf will 
reduce mistakes but having another for container would be even better. 
That said, I have yet to think of a good convention
Like you said, this would be the third time for link-msd(s). I'll see what my 
co-authors think. 


In passing, must link-msd be >= node-msd?
Yes - this is clear in the associated MSD protocol drafts. 

> 
>
>
>   And who needs the
>  container?  This is mpls not a common module that might be augmented 
so
>  what does the container give apart from complexity?
>
>  list policy
>leaf string
>  YANG string caters for very large items of very complex character 
sets.
>Is that desirable?
> 
> IETF models normally do not limit identifiers. An individual 
implementation could do this with a deviation.


I know - I did see an AD challenge that, I think in IESG review, not 
long ago.  SMI was better at this!

Since we have standardized on a maximum length for identifiers or even policy 
identifiers, I'm not going to pick one specific to this draft. It goes without 
saying that implementations will have a limit. 

Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard

[Acee Lindem (acee)]

Hi Tom, 

See a couple responses inline enclosed in  and . We are addressing 
the rest of your comments. 

On 11/18/20, 7:39 AM, "tom petch"  wrote:

IANA Considerations does not register the module names used in the modules


This is in the IANA considerations... 

   This document registers a YANG module in the YANG Module Names
   registry [RFC6020].

  name: ietf-segment-routing-common
  namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common
  prefix: sr-cmn
  reference: RFC 

  name: ietf-segment-routing
  namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing
  prefix: sr
  reference: RFC 

  name: ietf-segment-routing
  namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
  prefix: sr-mpls
  reference: RFC 


Examples are IPv4 only, IPv6 would be good

BGP is included when it comes to defining a router-id but is ignored 
everywhere else, such as signalling MSD, protocol extensions etc

reference "RFC " would be improved by including the title in all 
cases not just some

the scheme http: appears in many places.  It would be lovely if this 
really was the scheme but I fear that it is not

This is directly from the RFC 8407 template in Appendix B. What would you 
suggest? 


module srcmn
  the upper bound must be larger
  the value must be greater
consistency is good - I think greater is better

8.3
operation states
usually operational

two imports lack references

typedef router-id
this is a well known type from RFC8394; it seems likely to confuse to 
redefine it with a related but different meaning

leaf enabled
enables protocol extensions
which protocols?

leaf protected
it is used to protect
how does it do that:-)

enum dual
... In this case will be advertised with backup flag set
What is the backup flag?  It does not feature in RFC8660.  Needs an 
explanation and reference

container link-msd
  list link-msds
leaf msd
The usual YANG convention is for a list to be plural and the leaf 
singular.  You have the plural list but not the leaf. 
 
So you are asking for a change from "leaf msd" to "leaf link-msd"? 



 And who needs the 
container?  This is mpls not a common module that might be augmented so 
what does the container give apart from complexity?

list policy
  leaf string
YANG string caters for very large items of very complex character sets. 
  Is that desirable?

IETF models normally do not limit identifiers. An individual implementation 
could do this with a deviation. 
 

Thanks,
Acee

leaf used
will used plus free equal size?

Indicates if the binding is /instal/installed/

notification-segment-routing-global-srgb-collision
a mix of conflict and collision;  consistency is good and I prefer the 
latter which is the name of the notification

containing /s/a/ mapping

... sid collision
again consistency good, prefer collision to conflicting

s.9
I would have thought the srgb worthy of mention under sensitive nodes

Tom Petch


On 16/11/2020 19:32, The IESG wrote:
>
> The IESG has received a request from the Source Packet Routing in 
Networking
> WG (spring) to consider the following document: - 'YANG Data Model for
> Segment Routing'
> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits 
final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2020-11-30. Exceptionally, comments 
may
> be sent to i...@ietf.org instead. In either case, please retain the 
beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document defines a YANG data model for segment routing
> configuration and operation, which is to be augmented by different
> segment routing data planes.  The document also defines a YANG model
> that is intended to be used on network elements to configure or
> operate segment routing MPLS data plane, as well as some generic
> containers to be reused by IGP protocol modules to support segment
> routing.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

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

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

[Acee Lindem (acee)]

Hi Loa, 

In most cases, I believe that if the component acronyms are either well-known 
or expanded, there is no requirement to expand the hyphenated combination 
acronym. 

Thanks,
Acee

On 10/30/20, 12:32 AM, "spring on behalf of Loa Andersson" 
 wrote:

Working Group,

I support adopting this document.

However I have one question; if it leads to (very small) changes in the 
document, this can be done after the adoption.

I'm looking at

HMAC-SHA: Consists of two parts
HMAC: Hashed Message Authentication Code (expanded in the document).
SHA: Secure Hash Algorithm (not expanded, but on the other hand it an
 well-known abbreviation)

When we combine two abbreviations what rules apply, is it enough that 
eachpart is expanded "somewhere" even if the parts are found at 
different places. Or does the rule "expand at first occurrence apply?

I guess that in part this depends on whether we view HMAC-SHA as one 
unit or two separate parts? And how familiar we believe our readers are 
with the abbreviations.

I don't have a strong opinion on this, but would suggest that we place
HMAC-SHA in the "Abbreviations" in section 2.2 and expamnd it fully.

On 30/10/2020 10:01, Chengli (Cheng Li) wrote:
> Hi WG,
> 
> Support. However, there are some encoding format changes among versions, 
> hope the encoding format can be stable in the following revision ASAP.
> 
> Many thanks for the authors’ contribution!
> 
> Thanks,
> 
> Cheng
> 
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *James 
> Guichard
> *Sent:* Thursday, October 22, 2020 8:52 PM
> *To:* spring@ietf.org
> *Cc:* ippm-cha...@ietf.org; spring-cha...@ietf.org
> *Subject:* [spring] WG Adoption Call for 
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
> 
> Dear WG:
> 
> This message starts a 3 week WG adoption call for document 
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending 
> November 12^th 2020. Please note that this document has several changes 
> from v-10 that were requested by the SPRING and IPPM chairs. For this 
> reason, the chairs have extended the adoption call for an additional 
> week to allow the WG enough time to review these changes before deciding 
> on WG adoption.
> 
> Some background:
> 
> Several review comments were received previously for document 
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The 
> SPRING and IPPM chairs considered those comments, and upon review of 
> this version of the document, determined the following:
> 
>   * The SPRING document should describe only the procedures relevant to
> SPRING with pointers to non-SPRING document/s that define any
> extensions. Several extensions including*Control Code Field
> Extension for TWAMP Light Messages*, *Loss Measurement Query Message
> Extensions*, and *Loss Measurement Response Message Extensions *were
> included in
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and
> should be removed from the SPRING document.
>   * The TWAMP extensions included in
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should
> be described in a new document published in the IPPM WG. 
> 
> These conclusions were discussed with the authors of 
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result 
> of which is the publication of the following two documents:
> 
>   * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The
> subject of this WG adoption call.
>   * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This
> document will be progressed (if determined by the WG) within the
> IPPM WG.
> 
> After review of the SPRING document please indicate support (or not) for 
> WG adoption to the mailing list. Please also provide comments/reasons 
> for that support (or lack thereof) as silence will not be considered as 
> consent.
> 
> Finally, the chairs would like to thank the authors for their efforts in 
> this matter.
> 
> Thanks!
> 
> Jim, Bruno, & Joel
> 
> //
> 
> 
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 

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

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

___
spring 

Re: [spring] WG LC https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/

[Acee Lindem (acee)]

Support as co-author.

Thanks,
Acee

From: spring  on behalf of James Guichard 

Date: Tuesday, June 23, 2020 at 1:59 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG LC 
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/

Dear SPRING WG:

This email starts a two week WG LC for 
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/.

Substantive comments should be directed to the mailing list no later than July 
7th. Editorial suggestions can be sent to the authors.

Thanks!

Jim, Joel & Bruno

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

Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Acee Lindem (acee)]

Speaking as WG member:

In the past, we developed protocol encodings that afforded future 
extendibility. I don't see the problem with the including the SID structure 
sub-sub-TLV and would support progression.

Thanks,
Acee

On 4/10/20, 2:45 AM, "Lsr on behalf of Derek Yeung"  wrote:

Hi,

We at Arrcus have implemented support for this draft including the SID 
Structure sub-sub-TLV.
The proposed encodings for the SID Structure sub-sub-TLV is flexible and 
works fine.

Thanks,
Derek

Derek Yeung
de...@arrcus.com
Main: 408.884.1965



2077 Gateway Place, Suite 400
San Jose, CA.  95110

The contents of this message, together with any attachments, are intended 
only for the use of the individual or entity to which they are addressed and 
may contain information that is confidential and proprietary to Arrcus. If you 
are not the intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this message, or any attachment, is strictly 
prohibited. If you have received this message in error, please notify the 
original sender immediately by telephone or by return E-mail and delete this 
message, along with any attachments, from your computer. Thank you.


On 4/6/20, 4:03 AM, "Lsr on behalf of Peter Psenak"  wrote:

Chris,

On 01/04/2020 21:58, Chris Bowers wrote:
> Peter,
> 
> There seem to be two disconnects in this discussion.
> 
> 1) The response below implies that the encodings in 
> draft-ietf-lsr-isis-srv6-extensions are supposed represent the case 
> where the locators are allocated from several different IPv6 address 
> blocks (for example, blocks S1/s1 through Sn/sn). However, 
> draft-ietf-spring-srv6-network-programming and 
> draft-ietf-6man-segment-routing-header only discuss the case where 
the 
> locators are allocated from a single block (S/s).  If an 
implementation 
> is expected to properly encode the case where locators are allocated 
> from several different IPv6 address blocks, then I think that case 
> should be explicitly described in these documents.


There is no statement in draft-ietf-spring-srv6-network-programming 
that 
the block is unique. As an example, Iliad authorized me to indicate 
that 
their SRv6 deployment involves several blocks.


> 
> 2)   The response below says "To be able to find out where the func 
and 
> arg are located, you need to know the LOC length, e.g. Block and Node 
> length."  However, the SRv6 SID Structure Sub-Sub-TLV is carried 
within 
> the SRv6 End SID, SRv6 End.X SID, and the SRv6 LAN End.X SID 
Sub-TLVs, 
> which are carried within the SRv6 Locator TLV.  

not really. SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs are 
advertised in the IS Reachability TLVs (22, 23, 222, 223, 141), not in 
SRv6 Locator TLV.

thanks,
Peter


> The  SRv6 Locator TLV 
> has a Loc-Size field.  Why would the value of the LOC length computed 
as 
> the sum of the Block and Node length ever be different from the value 
in 
> the Loc-Size field?
> 
> Chris
> 
> 
> On Wed, Mar 25, 2020 at 9:49 AM Peter Psenak  > wrote:
> 
> Chris,
> 
> please see inline:
> 
> 
> On 23/03/2020 17:39, Chris Bowers wrote:
>  > Peter,
>  >
>  > The proposed SRv6 SID Structure Sub-Sub-TLV has several 
problems.
>  >
>  > 1) As discussed in item#3 below, it is not clear that flooding 
LB
>  > Length, LN Length, Fun. Length, and Arg. Length to all ISIS
> speakers is
>  > really the right approach.  However, if the WG determines that 
it
> is the
>  > right approach, the current encodings of this information in 
the
>  > proposed SRv6 SID Structure Sub-Sub-TLV are problematic.  As
> discussed
>  > earlier in this thread, a network operator may choose to not
> allocate
>  > all locators from a single block, so LB Length and LN Length 
may
> not be
>  > well-defined.
> 
> I'm not sure what do you mean by not "well defined". For every 
SID you
> need to know the LOC (B+N) part. If you guarantee that it is the
> same on
> all nodes, you know it from the local config, otherwise, you 
advertise
> it with a SID.
> 
>  > The current encoding of the SRv6 SID Structure
>  > Sub-Sub-TLV makes it difficult to represent this situation.  
The
> simple
>  > thing to do for nodes that don't have a 

Re: [spring] Updates to draft-hu-spring-segment-routing-proxy-forwarding

[Acee Lindem (acee)]

Hi Huaimo,
This is good as far as my comments on the encoding and draft name. This draft 
is somewhat new territory as you have an IGP router which is not the source of 
the prefix originating an LSA for the prefix.
Thanks,
Acee

From: spring  on behalf of Huaimo Chen 

Date: Monday, November 11, 2019 at 9:37 AM
To: "spring@ietf.org" 
Subject: Re: [spring] Updates to 
draft-hu-spring-segment-routing-proxy-forwarding

Hi Acee,

Thank you very much for your comments and suggestions on the draft during 
IETF 104 meeting (as I remembered: you indicated: the title is not fit, router 
informational capability TLV should be changed to router functional capability 
TLV).

We have addressed these in the updated version, in which the title is 
changed to  SR-TE Path Midpoint Protection from Segment Routing Proxy 
Forwarding, and the router informational capability TLV is changed to router 
functional capability TLV.

Would you mind reviewing them? Thanks much for your time.

Best Regards,
Huaimo

From: spring  on behalf of Huaimo Chen 

Sent: Sunday, November 10, 2019 11:09 PM
To: spring@ietf.org 
Subject: [spring] Updates to draft-hu-spring-segment-routing-proxy-forwarding

Hi Everyone,

The changes in -06 version include the followings (details in the diff file 
attached). Can you review them? Your comments and suggestions are very welcome.

 1) The title of the draft, which is changed to SR-TE Path Midpoint Protection 
from Segment Routing Proxy Forwarding. This is to address the 
comment/suggestion during IETF 104 meeting (my face to face presentation).
  2) IGP protocol extensions change such as using Router Functional Capability 
TLV instead of Router Information Capability TLV. This is also to address the 
comment/suggestion during IETF 104 meeting (my presentation).
  3) Added section Security Considerations
  4) Added section IANA Considerations
  5) Added one co-author
  6) Added some references
  7) Some editorial changes.

Best Regards,
Huaimo
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-ietf-spring-sr-yang: question about absolute SIDs

[Acee Lindem (acee)]

Hi Renato, +SPRING WG,

It is an MPLS label (i.e., your option 2).

Excerpted from RFC 8402:

3.1.2.  SR-MPLS

   When SR is used over the MPLS data plane, SIDs are an MPLS label or
   an index into an MPLS label space (either SRGB or SRLB).

We’ll make this clear by rewording “absolute value” to avoid the mathematical 
connotation.

Thanks,
Acee


From: Renato Westphal 
Date: Friday, September 13, 2019 at 11:17 AM
To: "draft-ietf-spring-sr-y...@ietf.org" , 
"slitkows.i...@gmail.com" 
Cc: Olivier Dugeon 
Subject: draft-ietf-spring-sr-yang: question about absolute SIDs
Resent-From: 
Resent-To: Stephane Litkowski , 
, Acee Lindem , Pushpasis Sarkar 
, Jeff Tantsura 
Resent-Date: Friday, September 13, 2019 at 11:17 AM

Hi all,

I have a quick question about the ietf-segment-routing-common YANG module.

Prefix-SIDs can be configured using either an index or an absolute label, as 
specified by the "value-type" leaf below:

leaf value-type {
  type enumeration {
enum "index" {
  description
"The value will be interpreted as an index.";
}
enum "absolute" {
  description
"The value will become interpreted as an absolute
 value.";
}
  }
  default "index";
  description
"This leaf defines how value must be interpreted.";
}

I think the draft it not very clear about what an absolute value means. There 
are two possible interpretations:
1. The absolute value must be mapped to a SID index and must be within the SRGB 
range (as documented on Clarence's book, and this is also what IOS-XR does). 
The Prefix-SID V/L flags are set to 0.
2. The absolute value represents an MPLS label that can be outside the SRGB 
range. The Prefix-SID V/L flags are set to 1.

Which one would be the correct interpretation? I tend to think #1 is the 
intended design, but I'd like to hear a confirmation from the draft authors to 
be sure about it.

Thanks in advance,
--
Renato Westphal
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Lsr] Adjacency SID and Passive Interface

[Acee Lindem (acee)]

Hi Chris, Olivier, 

On 5/10/19, 4:41 AM, "Lsr on behalf of Christian Franke"  wrote:

On 5/10/19 9:58 AM, olivier.dug...@orange.com wrote:
> In the current state of Segment Routing drafts, do you think it is 
possible to advertise
> Adjacency SID on such passive or inter-domain interfaces or do we need to 
specify this behaviour
> in a new draft ?
> 
> For me I don't see anything in the drafts that prohibits this kind of 
advertisement, but perhaps I'm wrong.

My understanding is that the SID is specific to an adjacency and
advertised in IS-IS in either TLV 22, 222, 23, 223.

As adjacencies will not be formed on a passive interface, an adjacency
SID should not be advertised for the passive interface.

I agree with Chris. We shouldn't reuse the existing Adj-SID when there will 
never be an adjacency and the current semantics require this. If we need 
advertisement of SIDs for passive interfaces, it would definitely be a new 
draft that clearly articulates the use case and designates a new type of SID 
that has different semantics. Also note that while passive interfaces are very 
useful in order to include a stub network in the topologies, they are not part 
of the OSPF specifications. I haven't done an exhaustive search on IS-IS. 

Thanks,
Acee


I might also be wrong here, though.

All Best,
Chris

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


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

[spring] Status of "Segment Routing with MPLS data plane" - draft-ietf-spring-segment-routing-mpls-18

[Acee Lindem (acee)]

Authors, Martin,

What is the status of this draft? It is currently blocking publication of all 
the initial (MPLS)a LSR segment routing drafts and it seems to have stalled.

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

Re: [spring] New Version of draft-farrel-spring-sr-domain-interconnect

[Acee Lindem (acee)]

Hi Adrian, 

On 10/13/18, 1:11 PM, "spring on behalf of Adrian Farrel" 
 wrote:

Hi,

Nothing much happening with this draft.

The new revision fixes a reference.

We think our work here is done although it is disappointing that a couple 
of (informative) references have expired:
- I-D.sivabalan-pce-binding-label-sid
- I-D.ietf-idr-bgpls-segment-routing-epe

I just reviewed a new version of the latter draft (as a contributor) and it 
will be refreshed shortly. The refresh was delayed to address all of Sue Hares' 
shepherd review comments. 

Thanks,
Acee


We would still welcome comments.

Thanks,
Adrian

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: 13 October 2018 18:04
> To: Adrian Farrel; John Drake
> Subject: New Version Notification for 
draft-farrel-spring-sr-domain-interconnect-
> 05.txt
> 
> 
> A new version of I-D, draft-farrel-spring-sr-domain-interconnect-05.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
> 
> Name: draft-farrel-spring-sr-domain-interconnect
> Revision: 05
> Title:Interconnection of Segment Routing Domains - Problem
> Statement and Solution Landscape
> Document date:2018-10-13
> Group:Individual Submission
> Pages:35
> URL:
https://www.ietf.org/internet-drafts/draft-farrel-spring-sr-domain-
> interconnect-05.txt
> Status: 
https://datatracker.ietf.org/doc/draft-farrel-spring-sr-domain-
> interconnect/
> Htmlized:   https://tools.ietf.org/html/draft-farrel-spring-sr-domain-
> interconnect-05
> Htmlized:   
https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-
> interconnect
> Diff:   
https://www.ietf.org/rfcdiff?url2=draft-farrel-spring-sr-domain-
> interconnect-05
> 
> Abstract:
>Segment Routing (SR) is a forwarding paradigm for use in MPLS and
>IPv6 networks.  It is intended to be deployed in discrete domains
>that may be data centers, access networks, or other networks that are
>under the control of a single operator and that can easily be
>upgraded to support this new technology.
> 
>Traffic originating in one SR domain often terminates in another SR
>domain, but must transit a backbone network that provides
>interconnection between those domains.
> 
>This document describes a mechanism for providing connectivity
>between SR domains to enable end-to-end or domain-to-domain traffic
>engineering.
> 
>The approach described allows connectivity between SR domains,
>utilizes traffic engineering mechanisms (RSVP-TE or Segment Routing)
>across the backbone network, makes heavy use of pre-existing
>technologies, and requires the specification of very few additional
>mechanisms.
> 
>This document provides some background and a problem statement,
>explains the solution mechanism, gives references to other documents
>that define protocol mechanisms, and provides examples.  It does not
>define any new protocol mechanisms.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

___
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

Re: [spring] Yang data model for SID forwarding counters

[Acee Lindem (acee)]

Hi Tim,

From: spring  on behalf of "Yutianpeng (Tim)" 

Date: Thursday, August 16, 2018 at 4:41 PM
To: "spring@ietf.org" 
Subject: [spring] Yang data model for SID forwarding counters

Hi,
I am trying to find data model for SID forwarding counters, but I only find 
SRV6 based counters in “draft-raza-spring-srv6-yang-00”.

We will take this under consideration.

I think it is quite important to have YANG data models for IGP based or BGP EPE 
also.

These exist.

Thanks,
Acee
Can we put this inside “draft-ietf-spring-sr-yang”? It might be better to put 
this inside a common data model instead of per protocol basis one.

Thanks & Regards,
Tim
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Working Group Adoption Call for draft-filsfils-spring-segment-routing-policy

[Acee Lindem (acee)]

Speaking as a SPRING WG member who is not a Co-Author,

I support WG adoption.

Thanks,
Acee

From: spring  on behalf of Rob Shakir 

Date: Wednesday, May 16, 2018 at 11:21 AM
To: SPRING WG List 
Subject: [spring] Working Group Adoption Call for 
draft-filsfils-spring-segment-routing-policy

Hi SPRING WG,

This email initiates a two week call for working group adoption for 
draft-filsfils-spring-segment-routing-policy. Please indicate your support, or 
otherwise, for adopting this draft as a working group item by 30th May 2018. We 
are particularly interested in hearing from working group members that are not 
co-authors of this draft.

As part of the discussions of adopting this draft into SPRING with the ADs and 
chairs of other WGs, there are a number of requests to the authors.

1. Please clarify in the text traffic steering with "SR policy" and its 
relationship to other traffic engineering functions. It seems to me that this 
work is generally describing how one selects and steers traffic into policies, 
rather than path calculation. Additional clarification of whether this is the 
case (or not), would be welcome to ensure that the relationship with other work 
is clear. We would ask the authors to consider whether sections 14.1-14.4 are 
required scope of this document.

2.. Consider what the core content of this document is, and how it can be make 
as concise and clear as possible. There are some specific suggestions that can 
be made here, but we would like to see this discussed with the working group.

Additionally, there are currently 17 authors listed on this document. Please 
trim this to <= 5 front-page authors, utilising a "Contributors" section if 
required for the others.. An approach to achieving this would be to list ~2 
editors as the front-page authors.

In parallel to this adoption call, I will send an IPR call for this document. 
We will need all 17 authors to confirm their IPR position on this document.

Thanks,
Bruno & Rob.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [OSPF] Experimental support of OSPFv2 Segment Routing in Free Range Routing

[Acee Lindem (acee)]

Hi Olivier,

Great news Olivier! I’m hoping you are looking at OSPFv3 Extended LSAs and 
OSPFv3 SR as well.

Thanks,
Acee

From: OSPF  on behalf of Olivier Dugeon 

Date: Tuesday, February 6, 2018 at 3:13 PM
To: SPRING WG List , OSPF WG List 
Subject: [OSPF] Experimental support of OSPFv2 Segment Routing in Free Range 
Routing

Hi all,

We are please to announce that we have added Experimental support of OSPF SR
(draft-ietf-ospf-segment-routing-extensions-24) in Free Range Routing
protocol suite https://frrouting.org

This feature is available on the master branch: https://github.com/FRRouting/frr
and will be part of the future 4.0 release.

Supported Features:

* Automatic computation of Primary and Backup Adjacency SID with
Cisco experimental remote IP address
* SRGB configuration
* Prefix configuration for Node SID with optional NO-PHP flag (Linux
kernel support both mode)
* Node MSD configuration (with Linux Kernel >= 4.10 a maximum of 32 labels
could be stack)
* Automatic provisioning of MPLS table
* Static route configuration with label stack up to 32 labels

Interoperability:
* tested on various topology including point-to-point and LAN interfaces
in a mix of Free Range Routing instance and Cisco IOS-XR 6.0.x
* check OSPF LSA conformity with latest wireshark release 2.5.0-rc

Known limitations

* Runs only within default VRF
* Only single Area is supported. ABR is not yet supported
* Only SPF algorithm is supported
* Extended Prefix Range is not supported
* MPLS table are not flush at startup. Thus, restarting zebra process is
  mandatory to remove old MPLS entries in the data plane after a crash of
  ospfd daemon
* With NO Penultimate Hop Popping, it is not possible to express a Segment
  Path with an Adjacency SID due to the impossibility for the Linux Kernel to
  perform double POP instruction.

For details implementation & instructions on how to use this new feature,
please consult doc/OSPF-SR.rst.

Regards

FRR team




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

Re: [spring] [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

[Acee Lindem (acee)]

Actually, support as a contributor to the document.
Thanks,
Acee 

On 12/9/17, 7:00 AM, "mpls on behalf of Acee Lindem (acee)"
<mpls-boun...@ietf.org on behalf of a...@cisco.com> wrote:

>Support - this is an important document that captures the extensive
>discussion on the topic.
>Thanks,
>Acee 
>
>On 12/9/17, 2:35 AM, "mpls on behalf of Henderickx, Wim (Nokia -
>BE/Antwerp)" <mpls-boun...@ietf.org on behalf of wim.henderi...@nokia.com>
>wrote:
>
>>Support as co-author
>>
>>On 08/12/2017, 21:33, "mpls on behalf of Jeff Tantsura"
>><mpls-boun...@ietf.org on behalf of jefftant.i...@gmail.com> wrote:
>>
>>Loa,
>>
>>Support as co-author.
>>Thanks!
>>
>>Cheers,
>>Jeff
>>
>>-Original Message-
>>From: mpls <mpls-boun...@ietf.org> on behalf of Loa Andersson
>><l...@pi.nu>
>>Date: Friday, December 8, 2017 at 05:17
>>To: "m...@ietf.org" <m...@ietf.org>
>>Cc: "spring@ietf.org" <spring@ietf.org>, "mpls-cha...@ietf.org"
>><mpls-cha...@ietf.org>, <draft-ietf-mpls-spring-entropy-la...@ietf.org>
>>Subject: [mpls] working group last call on
>>draft-ietf-mpls-spring-entropy-label
>>
>>Working Group,
>>
>>This is to initiate a two week working group last call on draft-
>>ietf-mpls-spring-entropy-label.
>>
>>Please send your comments to the mpls wg mailing list
>>(m...@ietf.org).
>>
>>Since this is a second wglc on this document, the current
>>document
>>address all comments all comments from the previous wglc, but it
>>is
>>more than 18 months since the previous wqglc, we have decided to
>>do
>>a full two week call.
>>
>>There are no IPRs disclosed against
>>draft-ietf-mpls-spring-entropy-
>>label.
>>
>>All the authors and contributors have stated on the working group
>>mailing list that they are not aware of any other IPRs that
>>relates
>>to this document.
>>
>>This working group last call ends December 22, 2017.
>>
>>This wglc is copied to the SPRING wg mailing list, please address
>>all
>>comments to m...@ietf.org.
>>
>>
>>/Loa
>>MPLS wg co-chair
>>-- 
>>
>>
>>Loa Anderssonemail: l...@pi.nu
>>Senior MPLS Expert
>>Huawei Technologies (consultant) phone: +46 739 81 21 64
>>
>>___
>>mpls mailing list
>>m...@ietf.org
>>https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>
>>___
>>mpls mailing list
>>m...@ietf.org
>>https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>___
>>mpls mailing list
>>m...@ietf.org
>>https://www.ietf.org/mailman/listinfo/mpls
>
>___
>mpls mailing list
>m...@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls

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

Re: [spring] [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

[Acee Lindem (acee)]

Support - this is an important document that captures the extensive
discussion on the topic.
Thanks,
Acee 

On 12/9/17, 2:35 AM, "mpls on behalf of Henderickx, Wim (Nokia -
BE/Antwerp)" 
wrote:

>Support as co-author
>
>On 08/12/2017, 21:33, "mpls on behalf of Jeff Tantsura"
> wrote:
>
>Loa,
>
>Support as co-author.
>Thanks!
>
>Cheers,
>Jeff
>
>-Original Message-
>From: mpls  on behalf of Loa Andersson
>
>Date: Friday, December 8, 2017 at 05:17
>To: "m...@ietf.org" 
>Cc: "spring@ietf.org" , "mpls-cha...@ietf.org"
>, 
>Subject: [mpls] working group last call on
>draft-ietf-mpls-spring-entropy-label
>
>Working Group,
>
>This is to initiate a two week working group last call on draft-
>ietf-mpls-spring-entropy-label.
>
>Please send your comments to the mpls wg mailing list
>(m...@ietf.org).
>
>Since this is a second wglc on this document, the current document
>address all comments all comments from the previous wglc, but it
>is
>more than 18 months since the previous wqglc, we have decided to
>do
>a full two week call.
>
>There are no IPRs disclosed against
>draft-ietf-mpls-spring-entropy-
>label.
>
>All the authors and contributors have stated on the working group
>mailing list that they are not aware of any other IPRs that
>relates
>to this document.
>
>This working group last call ends December 22, 2017.
>
>This wglc is copied to the SPRING wg mailing list, please address
>all
>comments to m...@ietf.org.
>
>
>/Loa
>MPLS wg co-chair
>-- 
>
>
>Loa Anderssonemail: l...@pi.nu
>Senior MPLS Expert
>Huawei Technologies (consultant) phone: +46 739 81 21 64
>
>___
>mpls mailing list
>m...@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>___
>mpls mailing list
>m...@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls
>
>
>___
>mpls mailing list
>m...@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls

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

Re: [spring] Slot request for IETF 100

[Acee Lindem (acee)]

Hi Shraddha,

If your SR traffic statistics draft progresses, the ietf-segment-routing model 
would need to be augmented. I don’t see having the YANG model augmentations as 
a prerequisite.

Thanks,
Acee

From: spring > on 
behalf of Shraddha Hegde >
Date: Thursday, November 2, 2017 at 11:53 PM
To: Mahesh Jethanandani 
>
Cc: "spring@ietf.org" 
>, Adrian Farrel 
>
Subject: Re: [spring] Slot request for IETF 100

Mahesh,

I have only seen https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang for 
YANG and it does not have
Anything related to traffic statistics counters AFAIK.
Is there any other model that I am not aware of?

Rgds
Shraddha

From: Mahesh Jethanandani [mailto:mjethanand...@gmail.com]
Sent: Friday, November 3, 2017 8:53 AM
To: Shraddha Hegde >
Cc: spring@ietf.org; Adrian Farrel 
>
Subject: Re: [spring] Slot request for IETF 100

Shraddha,

Could this traffic accounting format be represented as a YANG module? If so, 
can it be part of an existing SR YANG module or would you define a new model?

On Nov 3, 2017, at 12:14 AM, Shraddha Hegde 
> wrote:

Chairs,

I would like to request a 10 min slot to present the below draft.
https://tools.ietf.org/html/draft-hegde-spring-traffic-accounting-for-sr-paths-01


Thanks
Shraddha

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

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

[Acee Lindem (acee)]

Hi Les, 

I agree with the responses.

On 7/11/17, 3:46 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> wrote:

>Acee -
>
>Thanx for your support abd your comments.
>Responses inline.
>
>> -Original Message-
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Acee Lindem
>> (acee)
>> Sent: Tuesday, July 11, 2017 12:02 PM
>> To: bruno.decra...@orange.com; Martin Vigoureux
>> Cc: spring@ietf.org
>> Subject: Re: [spring] WG Last Call for
>>draft-ietf-spring-conflict-resolution
>> 
>> I fully support this document and, now that we have reached consensus,
>> believe we should publish it before anyone changes their minds…
>> 
>> I have reviewed the -05 version and have the following comments:
>> 
>> 1. Section 3.1 - Make it clear that a larger preference is more
>>preferred.
>> While this is stated in section 3.3, it must be inferred in section 3.1
>>to
>> understand the text.
>
>[Les:] Agreed.
>
>> 2. Expand acronyms on first use, e.g., SID and SRMS.
>
>[Les:] ACK
>
>> 3. In section 3.8, do we want to suggest that the conflicting
>>configuration
>> not be “accepted” rather than not “advertised”?
>> 
>[Les:] I don't think so.
>
>While it is possible that such a check could be run as each configuration
>line is entered, stating that this is the way it should be done
>constrains an implementation unnecessarily. That is certainly a
>reasonable way of implementing it, but not the only way. For example,  a
>node could allow SRMS configuration to be entered locally without
>validating it until the user indicates  "configuration complete". Then
>the conflict resolution algorithm could be run "as if the configured
>values were advertised" to detect conflicts before advertisement is
>enabled.
>
>I don’t think we care which way an implementation chooses to go - the
>useful bit is that the check is performed BEFORE the config is advertised
>and starts to be used.

That is reasonable.

Thanks,
Acee

>
>
>> I also have a number of editorial suggestions which I will sent to the
>>authors
>> offline.
>
>[Les:] Thanx for those as well.
>
>Les
>
>> 
>> Thanks,
>> Acee
>> 
>> On 7/11/17, 6:41 AM, "spring on behalf of bruno.decra...@orange.com"
>> <spring-boun...@ietf.org on behalf of bruno.decra...@orange.com>
>> wrote:
>> 
>> >Martin,
>> >
>> >As an individual contributor, I have read all versions of this document
>> >and support progressing -05 to the IESG.
>> >
>> >Unless we believe error never happen, a standardized conflict
>> >resolution procedure is needed to safely deploy MPLS Segment Routing in
>> >a multi-vendor network. Some implementations are waiting for this
>> >document to be advanced to RFC in order to implement the stable
>> behavior.
>> >
>> >IMO, -05 is ready:
>> >- "SR Global Block Inconsistency" is ready for months (>1 year)
>> >- "SR-MPLS Segment Identifier Conflicts" required more time to progress
>> >and explored multiple options, but after much work from the authors,
>> >-05 seems ready to me. For forwarding nodes, it defines a per FEC
>> >preference rule limiting the conflict resolution to only the FEC
>> >(prefix/SID) which indeed face conflicting advertisements. For non-
>> forwarding nodes (e.g.
>> >network controllers, PCE...), it allows more freedom in the SID to be
>> >used (or discarded), including a simplified procedure disregarding all
>> >conflicting entries.
>> >
>> >Thanks,
>> >Regards,
>> >--Bruno
>> > > -Original Message-
>> > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Martin
>> >Vigoureux
>> > > Sent: Monday, July 10, 2017 2:58 PM
>> > > To: spring@ietf.org
>> > > Subject: Re: [spring] WG Last Call for
>> >draft-ietf-spring-conflict-resolution
>> > >
>> > > WG,
>> > >
>> > > We are half-way through the WG Last Call and I am very surprised to
>> >only
>> > > see a single answer to it.
>> > >
>> > > I am not sure I'll move this forward with only silence as support.
>> > >
>> > > -m
>> > >
>> > > Le 29/06/2017 à 15:28, Martin Vigoureux a écrit :
>> > > > Hello Working Group,
>> > > >
>> > > > This email starts a Working Group Last Call on
>> > &

Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

[Acee Lindem (acee)]

I fully support this document and, now that we have reached consensus,
believe we should publish it before anyone changes their minds…

I have reviewed the -05 version and have the following comments:

1. Section 3.1 - Make it clear that a larger preference is more
preferred. While this is stated in section 3.3, it must be inferred in
section 3.1 to understand the text.
2. Expand acronyms on first use, e.g., SID and SRMS.
3. In section 3.8, do we want to suggest that the conflicting
configuration not be “accepted” rather than not “advertised”?

I also have a number of editorial suggestions which I will sent to the
authors offline. 

Thanks,
Acee 

On 7/11/17, 6:41 AM, "spring on behalf of bruno.decra...@orange.com"
 wrote:

>Martin,
>
>As an individual contributor, I have read all versions of this document
>and support progressing -05 to the IESG.
>
>Unless we believe error never happen, a standardized conflict resolution
>procedure is needed to safely deploy MPLS Segment Routing in a
>multi-vendor network. Some implementations are waiting for this document
>to be advanced to RFC in order to implement the stable behavior.
>
>IMO, -05 is ready:
>- "SR Global Block Inconsistency" is ready for months (>1 year)
>- "SR-MPLS Segment Identifier Conflicts" required more time to progress
>and explored multiple options, but after much work from the authors, -05
>seems ready to me. For forwarding nodes, it defines a per FEC preference
>rule limiting the conflict resolution to only the FEC (prefix/SID) which
>indeed face conflicting advertisements. For non-forwarding nodes (e.g.
>network controllers, PCE...), it allows more freedom in the SID to be
>used (or discarded), including a simplified procedure disregarding all
>conflicting entries.
>
>Thanks,
>Regards,
>--Bruno
> > -Original Message-
> > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Martin
>Vigoureux
> > Sent: Monday, July 10, 2017 2:58 PM
> > To: spring@ietf.org
> > Subject: Re: [spring] WG Last Call for
>draft-ietf-spring-conflict-resolution
> > 
> > WG,
> > 
> > We are half-way through the WG Last Call and I am very surprised to
>only
> > see a single answer to it.
> > 
> > I am not sure I'll move this forward with only silence as support.
> > 
> > -m
> > 
> > Le 29/06/2017 à 15:28, Martin Vigoureux a écrit :
> > > Hello Working Group,
> > >
> > > This email starts a Working Group Last Call on
> > > draft-ietf-spring-conflict-resolution-04 [1] which is considered
>mature
> > > and ready for a final working group review.
> > >
> > > ¤ Please read this document if you haven't read the most recent
> > > version yet, and send your comments to the list, no later than
> > > *21st of July*.
> > > Note that this is *not only* a call for comments on the document; it
>is
> > > also a call for support (or not) to publish this document as a
>Proposed
> > > Standard RFC.
> > >
> > > ¤ *Coincidentally*, we are also polling for knowledge of any IPR that
> > > applies to draft-ietf-spring-conflict-resolution, to ensure that IPR
>has
> > > been disclosed in compliance with IETF IPR rules (see RFCs 3979,
>4879,
> > > 3669 and 5378 for more details).
> > >
> > > If you are listed as an Author or Contributor of
> > > draft-ietf-spring-conflict-resolution-04 please respond to this email
> > > and indicate whether or not you are aware of any relevant IPR.
> > >
> > > Note that, as of today, no IPR has been disclosed against this
>document
> > > or its earlier versions.
> > >
> > > Thank you,
> > > Martin
> > >
> > > [1] 
>https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/
> > >
> > > ___
> > > 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
>
>__
>___
>
>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.

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Acee Lindem (acee)]

Hi Bruno,

From: Bruno Decraene 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Date: Monday, June 12, 2017 at 9:37 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, 
"draft-ietf-ospf-segment-routing-extensi...@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>"
 
<draft-ietf-ospf-segment-routing-extensi...@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>>,
 
"draft-ietf-isis-segment-routing-extensi...@ietf.org<mailto:draft-ietf-isis-segment-routing-extensi...@ietf.org>"
 
<draft-ietf-isis-segment-routing-extensi...@ietf.org<mailto:draft-ietf-isis-segment-routing-extensi...@ietf.org>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>, 
"isis...@ietf.org<mailto:isis...@ietf.org>" 
<isis...@ietf.org<mailto:isis...@ietf.org>>, OSPF WG List 
<o...@ietf.org<mailto:o...@ietf.org>>
Subject: RE: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would 
also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

Hi Acee, authors

2 clarification questions inline [Bruno]

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, June 09, 2017 4:46 PM
To: OSPF WG List; spring@ietf.org<mailto:spring@ietf.org>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Cc: 
draft-ietf-ospf-segment-routing-extensi...@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>
Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would 
also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

Corrected IS-IS WG alias – Please reply to this one.
Thanks,
Acee

From: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Date: Friday, June 9, 2017 at 10:42 AM
To: OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>
Cc: 
"draft-ietf-ospf-segment-routing-extensi...@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>"
 
<draft-ietf-ospf-segment-routing-extensi...@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>>
Subject: OSPFv2 Segment Routing Extensions ERO Extensions (would also effect 
OSPFv3 and IS-IS)

Hi OSPF, ISIS, and SPRING WGs,

As part of the Alia’s AD review, she uncovered the fact that the ERO extensions 
in 6.1 and 6.2 are specified as far as encoding but are not specified as far as 
usage in any IGP or SPRING document. As document shepherd,  my proposal is that 
they simply be removed since they were incorporated as part of a draft merge 
and it appears that no one has implemented them (other than parsing).
[Bruno] Is the option to move those Binding SID IGP extensions in a different 
(WG) document opened/considered? Any opinion on this?
If there is the energy to fully specify usage, than a separate document would 
make sense. I think there is a enough description of the binding SID in 
existing SPRING documents. However, it the ERO that is not specified.


We could also deprecate types (4-8) in the OSPFv2 Extended Prefix LSA Sub-TLV 
registry to delay usage of these code points for some time (or indefinitely ;^).
[Bruno] Are there reasons to make actions to delay/against such usage?
Since these are fully specified in the IGP Extensions, there are probably 
implementations that parse and validate the sub-TLVs.

Thanks,
Acee




Thanks
Regards,
--Bruno

Thanks,
Acee

_

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] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Acee Lindem (acee)]

Hi Bruno, 

Here is my view.  

On 6/12/17, 8:50 AM, "spring on behalf of bruno.decra...@orange.com"
<spring-boun...@ietf.org on behalf of bruno.decra...@orange.com> wrote:

>Hello SPRING WG,
>
>I'd like to encourage discussion on this thread.
>
>The related questions seem to be:
>- Binding SIDs:
>   -  Is there any implementation?
>   - Is it useful?
>   - Does it need to be specified?

Binding SIDs as an architectural concept are very useful and will be
leveraged by numerous use cases. For example, one implemented use case is
BGP SR-TE. 
>
>- Binding SIDs advertised in IGP:
>   -  Is there any implementation?
>- Is it useful?
>   - Does it need to be specified?

At least for OSPF(v3), we currently don’t see any usage of binding SIDs. I
believe there is a use case for IS-IS but I’ll defer to the authors of the
IS-IS SR draft and implementation to elaborate.

As for the Bind SID ERO extensions, to the best of my knowledge, they are
not implemented or used by either OSPF or IS-IS.

>
>As of today, there seem to be multiple SPRING (related) document that
>make reference (define/use) to the Binding SIDs. e.g.
>- architecture 
>https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3
>.5.2
>- MPLS instantiation
>https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#sect
>ion-2
>- non-protected paths
>https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#
>section-3.3
>- SR policies: 
>https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-0
>0#section-7
>
>
>However, it also seems a priori possible to define Binding SIDs and not
>advertised them in the IGP. (e.g. by keeping them local to the PCE)
>
>On a side note, if the Binding SIDs are removed from the IGP, do they
>need to be removed from the BGP-LS extensions? [+IDR chairs]

At least the ERO extensions should be removed.

Thanks,
Acee 
>
>Thanks,
>Regards,
>--Bruno
>
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Monday, June 12, 2017 10:18 AM
> > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
> > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
> > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions
>(would also effect
> > OSPFv3 and IS-IS) - REPLY TO THIS ONE
> > 
> > Hi,
> > 
> > I would like to get some feedback on the usage of the SID/Label
>Binding TLV.
> > 
> > Is there any implementation that uses SID/Label Binding TLV for
> > advertising the SID/Label binding to a FEC as specified in section 6 of
> > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
> > draft-ietf-isis-segment-routing-extensions-12?
> > 
> > If not, do we see this as something we want to preserve in the IGP SR
> > drafts?
> > 
> > ISIS uses The SID/Label Binding TLV to advertise
> > prefixes to SID/Label mappings, which is known to be supported by
> > several implementations and that piece needs to be preserved.
> > 
> > thanks,
> > Peter
> > 
> > On 09/06/17 19:04 , Peter Psenak wrote:
> > > Acee,
> > >
> > > my question is whether we need the whole section 6 and the SID/Label
> > > Binding Sub-TLV that it specifies. In OSPF Binding SID is not used
>for
> > > SRMS advertisement like in ISIS.
> > >
> > > thanks,
> > > Peter
> > >
> > >
> > >
> > > On 09/06/17 16:45 , Acee Lindem (acee) wrote:
> > >> Corrected IS-IS WG alias – Please reply to this one.
> > >> Thanks,
> > >> Acee
> > >>
> > >> From: Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>
> > >> Date: Friday, June 9, 2017 at 10:42 AM
> > >> To: OSPF WG List <o...@ietf.org <mailto:o...@ietf.org>>,
> > >> "spring@ietf.org <mailto:spring@ietf.org>" <spring@ietf.org
> > >> <mailto:spring@ietf.org>>, "i...@ietf.org <mailto:i...@ietf.org>"
> > >> <i...@ietf.org <mailto:i...@ietf.org>>
> > >> Cc: "draft-ietf-ospf-segment-routing-extensi...@ietf.org
> > >> <mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>"
> > >> <draft-ietf-ospf-segment-routing-extensi...@ietf.org
> > >> <mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>>
> > >> Subject: OSPFv2 Segment Routing Extensions ERO Extensions (would
>also
> > >> effect OSPFv3 and IS-IS)
> > >>
> &

Re: [spring] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Acee Lindem (acee)]

Corrected IS-IS WG alias – Please reply to this one.
Thanks,
Acee

From: Acee Lindem >
Date: Friday, June 9, 2017 at 10:42 AM
To: OSPF WG List >, 
"spring@ietf.org" 
>, 
"i...@ietf.org" >
Cc: 
"draft-ietf-ospf-segment-routing-extensi...@ietf.org"
 
>
Subject: OSPFv2 Segment Routing Extensions ERO Extensions (would also effect 
OSPFv3 and IS-IS)

Hi OSPF, ISIS, and SPRING WGs,

As part of the Alia’s AD review, she uncovered the fact that the ERO extensions 
in 6.1 and 6.2 are specified as far as encoding but are not specified as far as 
usage in any IGP or SPRING document. As document shepherd,  my proposal is that 
they simply be removed since they were incorporated as part of a draft merge 
and it appears that no one has implemented them (other than parsing). We could 
also deprecate types (4-8) in the OSPFv2 Extended Prefix LSA Sub-TLV registry 
to delay usage of these code points for some time (or indefinitely ;^).

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

Re: [spring] [Mapping Server] Conflict Resolution

[Acee Lindem (acee)]

From: spring > on 
behalf of "Les Ginsberg (ginsberg)" 
>
Date: Saturday, March 18, 2017 at 10:59 AM
To: Robert Raszuk >
Cc: "spring@ietf.org" 
>, "Peter Psenak (ppsenak)" 
>, tech_kals Kals 
>, "Stefano Previdi (sprevidi)" 
>, 
"martin.pi...@pantheon.tech" 
>
Subject: Re: [spring] [Mapping Server] Conflict Resolution

Robert -

From: rras...@gmail.com [mailto:rras...@gmail.com] On 
Behalf Of Robert Raszuk
Sent: Saturday, March 18, 2017 1:55 AM
To: Les Ginsberg (ginsberg)
Cc: tech_kals Kals; spring@ietf.org; 
martin.pi...@pantheon.tech; Stefano Previdi 
(sprevidi); Peter Psenak (ppsenak)
Subject: Re: [spring] [Mapping Server] Conflict Resolution

Hi Kals,

Sorry for missing the concept of "range" in mapping server TLV. Apologies - my 
omission !

Hi Les,

Two related questions while we are at this:

1. How can a mapping server advertise SID label on behalf of node which is not 
capable of its own advertisement without validation that such SID label is 
actually installed in the data plane of that "incapable" node ? If he does 
validate it .. how ?

[Les:] It is not the responsibility of the SRMS to validate that what has been 
configured is installed in any node’s forwarding plane – and it would be a 
“catch-22” situation if that were required since until a SID is advertised no 
label can be installed by any node.
If your argument is that there should be a SID advertised by the node which 
owns a prefix before SRMS advertises a SID, then it becomes impossible to 
support partial deployment where some prefixes are owned by SR incapable nodes.

Absolutely – this constraint defeats the whole purpose of an SRMS.



2. When you are making conflict resolution is there a check if the given prefix 
has actually been advertised as valid IP reachability and is installed in local 
RIB/FIB ?

[Les:] No. Having such a policy would introduce additional convergence issues. 
To know whether a given label was being used by a downstream node you would 
have to run conflict resolution from the POV of the downstream node because the 
output of that node’s conflict resolution calculation could be different than 
the local node’s output.

I’m not implying that this is even a viable option. However, I’ll point out 
that this wouldn’t even be possible since you could not guarantee that you had 
the complete set of mappings for the downstream node.

Thanks,
Acee





   Les


Kind regards,
R.


On Sat, Mar 18, 2017 at 6:49 AM, Les Ginsberg (ginsberg) 
> wrote:
Kals –

Please look closely at how to determine if there is a conflict.
From Section 3:

 Prf - Preference Value (See Section 3.1)
   Pi - Initial prefix
   Pe - End prefix
   L  - Prefix length
   Lx - Maximum prefix length (32 for IPv4, 128 for IPv6)
   Si - Initial SID value
   Se - End SID value
   R  - Range value (See Note 1)
   T  - Topology
   A  - Algorithm

   A Mapping Entry is then the tuple: (Prf, Src, Pi/L, Si, R, T, A)
   Pe = (Pi + ((R-1) << (Lx-L))
   Se = Si + (R-1)

And Section 3.2.1

  Given two mapping entries:

   (Prf, P1/L1, S1, R1, T1, A1) and
   (Prf, P2/L2, S2, R2, T2, A2)

   where P1 <= P2

   a prefix conflict exists if all of the following are true:

   1)(T1 == T2) && (A1 == A2)
   2)P1 <= P2
   3)The prefixes are in the same address family.
   2)L1 == L2
   3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2)

The preference rule as defined in the latest version of the draft (02):

1.  Higher preference value wins
   2.  Smaller range wins
   3.  IPv6 entry wins over IPv4 entry
   4.  Longer prefix length wins
   5.  Smaller algorithm wins
   6.  Smaller starting address (considered as an unsigned integer
   value) wins
   7.  Smaller starting SID wins
   8.  If topology IDs are NOT identical both entries MUST be ignored

Comments inline

From: tech_kals Kals [mailto:tech.k...@gmail.com]
Sent: Friday, March 17, 2017 1:09 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org; Peter Psenak (ppsenak); Stefano 
Previdi (sprevidi); 
martin.pi...@pantheon.tech
Subject: Re: [Mapping Server] Conflict Resolution

Hi Les,

 Sorry, I have not included my mapping entries in the previous mail. Please see 
the example here below.

 I am working with the RFC which doesn't support Preference Value, so please 
ignore it. And, my mapping entries would looks like.

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05

[Acee Lindem (acee)]

I support publication of this standards track document. It is essential
for co-existence and migration with/from LDP based MPLS control planes and
SR based MPLS control planes.

Thanks,
Acee 

On 2/6/17, 8:20 AM, "spring on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a 2-week Working Group Last Call on
>draft-ietf-spring-segment-routing-ldp-interop-05 [1].
>
>¤ Please read the document if you haven't read the most recent
>version yet, and send your comments to the list, no later than the
>*19th of February*.
>Note that this is *not only* a call for comments on the document; it is
>also a call for support (or not) to publish this document as a Proposed
>Standard RFC.
>
>¤ We have already polled for IPR knowledge on this document and all
>Authors have replied.
>IPR exists against this document and has been disclosed [2].
>
>Thank you
>
>M
>
>---
>[1] 
>https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-int
>erop/
>[2] 
>https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-spring
>-segment-routing-ldp-interop
>
>___
>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

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

[Acee Lindem (acee)]

Hi, 

I have read the document and support publication.

Thanks,
Acee 

On 1/27/17, 6:05 AM, "spring on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a 2-week Working Group Last Call on
>draft-ietf-spring-segment-routing-mpls-06 [1].
>
>¤ Please read the document if you haven't read the most recent
>version yet, and send your comments to the list, no later than the
>*12th of February*.
>Note that this is *not only* a call for comments on the document; it is
>also a call for support (or not) to publish this document as a Proposed
>Standard RFC.
>
>¤ We have already polled for IPR knowledge on this document and all
>Authors have replied.
>IPR exists against this document and has been disclosed [2].
>
>Thank you
>
>M
>
>---
>[1] 
>https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>[2] 
>https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-spring
>-segment-routing-mpls
>
>___
>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

Re: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm

[Acee Lindem (acee)]

Hi Les, Bruno,

See one inline.

From: spring > on 
behalf of "Les Ginsberg (ginsberg)" 
>
Date: Saturday, May 14, 2016 at 2:06 PM
To: Bruno Decraene 
>, 
"spring@ietf.org" 
>
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Preference 
Algorithm

Bruno  -

Thanx for your comments – inline.

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm

Hi authors, all

As an individual contributor, please find below some feedback to trigger 
discussion on the Preference Algorithm defined in §3.2.4.


>   1.  Smaller range wins
Looks ok to me, as this gives preference to Prefix-SID advertisement from SR 
routers which speaks for themselves/their own loopback/their own IP prefix 
advertisement; rather than SRMS advertisement which speaker for others. IOW, to 
know Brian’s SID, I’d rather believe Brian himself rather than George.

Also, this gives preference to SR nodes rather than LDP nodes (SRMS entries). 
Over the time/SR deployment, as more nodes gets SR, the number of nodes 
negatively impacted by the wrong configuration change is reduced.


Alternatively, I’d be fine to prefer Prefix-SID advertisement over SRMS 
advertisement. Actually, I’d propose to add this as rule 0. “0. Prefer 
Prefix-SID Sub-TLV over SID/Label Binding TLV”
I’ve been told OSPF can’t make the distinction, but I’m not sure to see the 
issue.

[Les:] (I don’t see the OSPF issue either.)

If it is a range advertisement, it is actually easier to detect in OSPF since a 
separate top-level TLV is used. For Prefix-SID, OSPF has the M-flag identifying 
mapping server advertisement.

Thanks,
Acee



This change is certainly possible. One reason we did not choose this direction 
is because it is just as possible to misconfigure local SID configuration 
associated with a prefix advertisement as it is to misconfigure an SRMS 
advertisement. In the event we are migrating nodes from being non-SR capable to 
SR capable we could have:

1.1.1.1/32 100 range 1 !SRMS advertisement
1.1.1.1/32 1000 range 1 !Prefix advertisement – added when a Node becomes SR 
capable

It seems more consistent to resolve based on the attributes of the 
advertisement rather than its source.


> 4.  Smaller prefix length wins
I’d rather have longer prefix length wins, and move this higher in position 3 
(*). Indeed, we usually primarily care to reach a specific egress node i.e. 
loopbacks destinations, which have the longest possible prefix length.
(*) It needs to be after IPv6 wins, to not conflict with it, as IPv6 have 
longer prefixes.



[Les:] I am fine with this change. I think the existing rules just used 
“smaller” as the tie breaker in all cases, but you have a point that in this 
case “longer” makes more sense.



   Les



>   3.  Smaller algorithm wins

>   5.  Smaller starting address (considered as an unsigned integer

   value) wins


I’m fine with this order, to privilege prefix diversity (typically for algo 0 
or 1) rather than algo diversity. (on the basis that to reach a node N, we need 
a SID for this node, while to follow algo N, we can use a combinations of 
segments from other algo).


So in summary, I’d propose discussing the following
OLD:

   1.  Smaller range wins

   2.  IPv6 entry wins over IPv4 entry

   3.  Smaller algorithm wins

   4.  Smaller prefix length wins

   5.  Smaller starting address (considered as an unsigned integer value) wins

   6.  Smaller starting SID wins

NEW:


   0.  Prefix-SID Sub-TLV wins over SID/Label Binding TLV

   1.  Smaller range wins

   2.  IPv6 entry wins over IPv4 entry

   3.  Longer prefix length wins

   4.  Smaller algorithm wins

   5.  Smaller starting address (considered as an unsigned integer value) wins

   6.  Smaller starting SID wins

Thanks,
Regards,
-- Bruno

_



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 

Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call

[Acee Lindem (acee)]

I support WG adoption. The conflict resolution document is required for
standard SID conflict error handling across all protocols and vendors.
Thanks,
Acee

On 4/14/16, 3:50 AM, "spring on behalf of bruno.decra...@orange.com"
 wrote:

>Dear WG,
>
>As we discussed at our meeting last week, working group adoption has been
>requested for draft-ginsberg-spring-conflict-resolution.
>Please reply to the list with your comments, including although not
>limited to whether or not you support adoption.
>
>Thanks,
>
>--John and Bruno
>
>
>
>__
>___
>
>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

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

Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

[Acee Lindem (acee)]

Since the ranges are all advertised by a single SR capable router and can 
easily be validated locally, I support this change.
Thanks,
Acee

From: spring > on 
behalf of "Les Ginsberg (ginsberg)" 
>
Date: Monday, January 4, 2016 at 12:55 AM
To: Bruno Decraene 
>, 
"spring@ietf.org" 
>
Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY


One of the topics discussed in 
https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ is 
how to handle inconsistent SRGB advertisements from a given node.



The draft defines one possible solution -from Section 2:



" Each range is examined in the order it was advertised.  If it does

   not overlap with any advertised range which preceded it the

   advertised range is used.  If the range overlaps with any preceding

   range it MUST NOT be used and all ranges advertised after the first

   encountered overlapping range also MUST NOT be used."



This is one instance of a class of solutions which attempt to make use of part 
of the advertisements even when there is some inconsistency (overlap) in the 
set of SRGB ranges received. A more complete discussion of this class of 
solutions can be seen in 
https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many thanx to 
Bruno for writing this.



However, there is an alternative solution which was suggested (notably by Acee 
Lindem) after the draft was written. This alternative is to ignore the entire 
set of SRGB advertisements and treat the problematic router as if it were not 
SR MPLS capable. This alternative was discussed during the presentation in 
SPRING WG at IETF94 (see 
https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf slide 
#3).
  It is also discussed in Bruno's post 
(https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see Section 
2.2).



The basis of the alternative solution is that a correct implementation should 
never allow inconsistent SRGB ranges to be successfully configured (let alone 
advertised). So this is not a case of a misconfiguration – it is a case of a 
defective implementation. It  then seems appropriate to put the onus on the 
originating router to only send valid SRGB advertisements rather than forcing 
all the receivers to try to "correct" the invalid information in some 
consistent way. This has a number of advantages:



1.   It is by far the simplest to implement

2.   It isolates the router which is untrustworthy

3.   As the problem can only occur as a result of a defective 
implementation the behavior of the originating router is unpredictable – it is 
therefore safer not to use the information



It is worth noting that since the invalid advertisement is the result of some 
sort of defect in the originating router’s implementation, it is not safe to 
assume that the source will actually be using the advertised SRGB in a manner 
consistent with the selective choice made by the receiving routers.



I therefore propose that the above quoted text from  
https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ be 
replaced with the following:



“The set of received ranges is examined . If there is overlap between any two 
of the advertised ranges the entire SRGB set is considered invalid and is 
ignored.

The originating router is considered to be incapable of supporting the SR-MPLS 
forwarding plane. Routers which receive an SRGB advertisement with overlapping 
ranges SHOULD report the occurrence.”



Comments?



   Les


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

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Acee Lindem (acee)]

Hi Eric, 

On 11/17/15, 12:15 PM, "Eric C Rosen"  wrote:

>On 11/17/2015 10:31 AM, Stefano Previdi (sprevidi) wrote:
>> to me it makes sense to advertise the SRGB along with ANY prefix
>> originated by that node, regardless the mask-length.
>
>But in that case, you don't know who the originator node is.  Could you
>explain to me how you use an SRGB when you don't know the node to which
>it belongs?

The use cases I came up with could definitely be accomplished with either
an additional label or recursive resolution through the Node-SID. However,
it still may be simpler operationally to advertise a Global Prefix-SID for
a locally attached subnet comprised of nodes offering a particular
service. 

With respect to the Originator SRGB, I never could fully appreciate the
advantages of advertising it. If you advertise an Originator SRGB, it
implies that there nodes with differing SRGBs in the BGP Routing Domain.
If this is the case, there is a very good chance that nodes receiving the
Prefix-SID Attribute with the Originator SRGB will not have the same SRGB
and will not have the Originator-SRGB[label-index] label available for
local allocation. I can’t really see what different it makes whether or
not it is a host prefix or whether you can ascertain the node to which the
SRGB belongs. It seems that the key constraint is that the label-index and
the SRGB came from the same node and this is always the case.


Thanks,
Acee 

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

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Acee Lindem (acee)]

Hi Eric, 

On 11/9/15, 10:22 AM, "spring on behalf of Eric C Rosen"
 wrote:

>Hi Stefano,
>
>>>If a BGP route is received that contains a Prefix-SID attribute
>>>with an
>>>Originator SRGB TLV, but the prefix field of the NLRI does not
>>>contain a
>>>host address, the attribute SHOULD be regarded as malformed. If a
>>>Prefix-SID attribute contains more than one SRGB TLV, it SHOULD be
>>>regarded as malformed.  See section 7 for the treatment of a
>>>malformed
>>>Prefix-SID attribute.
>>>
>>>When a route carrying the Prefix-SID attribute is propagated, the
>>>Originator SRGB TLV (if present) MUST NOT be changed.
>
>> why would you need such limitation ? A prefix may have a shorter mask
>> than 32 (or 128) and still be ok for the Originator SRGB to be there.
>
>The SRGB is a property of a node, not a property of a prefix.  To make
>use of the "Originator SRGB", you have to know the node whose property
>it is.  And you have to be able to tunnel packets to that node.  In the
>text I wrote above, the prefix field in the NLRI identifies the node to
>which the "Originator SRGB" belongs, and the prefix-SID field
>essentially gives you a node-SID that you can use to tunnel to the node
>in question.

I agree the predominant use case will be advertisement of a loopback.
However, independent of whether or not the Originator-SRGB TLV is
included, I see no reason why a BGP Speaker could not associate a
label-index with a locally attached subnet.

Thanks,
Acee 




>
>> The Originator-SRGB may only be inserted by the originator of the
>> prefix, maybe we should emphasize that, but the masklength is mostly
>> irrelevant here.
>
>I don't see that the Originator-SRGB TLV is useful without an explicit
>identification of the node whose SRGB it describes.  Certainly if you
>are trying to set up an explicitly routed path (perhaps as a loose
>source route) what you need are the node-SIDs are of the hops you want
>to specify, and the SRGB of each hop.
>
>When you talk about "the originator of the prefix", I think what you
>really mean is "the last node of the BGP prefix segment".  But I don't
>think that that term necessarily denotes a unique node, as there might
>be multiple ECMP paths to the prefix, and the prefix-SID does not
>distinguish among them.  E.g., the prefix itself might be multi-homed,
>or there might be multiple exit points from the SR domain, all of which
>are equidistant from the prefix.  In cases like that, you have no way of
>knowing whether a label computed from the Originator-SRGB is actually
>going to be correctly interpreted, because you don't really know the
>path a packet will take when it is labeled with the prefix-SID.
>
>Eric
>
>
>
>
>___
>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

Re: [spring] [SPRING] Query related to SR Architecture

[Acee Lindem (acee)]

Hi Anil,

From: "Anil Kumar S N (VRP Network BL)" 
<anil...@huawei.com<mailto:anil...@huawei.com>>
Date: Thursday, September 10, 2015 at 1:04 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Pushpasis Sarkar 
<psar...@juniper.net<mailto:psar...@juniper.net>>, Gaurav agrawal 
<gaurav.agra...@huawei.com<mailto:gaurav.agra...@huawei.com>>, Alexander 
Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Cc: "m...@ietf.org<mailto:m...@ietf.org>" 
<m...@ietf.org<mailto:m...@ietf.org>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>, Vinod Kumar S 70786 
<v70...@notesmail.huawei.com.cn<mailto:v70...@notesmail.huawei.com.cn>>
Subject: RE: [spring] [SPRING] Query related to SR Architecture

Hi Acee,

Thanks for your inputs. I might be wrong, correct me if i am.

Each node can advertise two different types service label for a same 
service.
a)  Service label after poping it, perform the service continue  with 
forwarding (current case)
b)  New kind of service label after poping it, perform/schedule the 
service and before forwarding push back the neighbors local service label.



Will this have backward compatibility issue ? as we are attaching more meaning 
to a service label which is new.
(new kind of service label processing will be done only be capable nodes who 
understand this new label type, capability must be exchanged to support 
backward compatibility)

In MPLS, one label is like any other label (except for the first 15 which are 
reserved). I think you are missing a whole lot of context here - you can’t just 
declare a new label type with different semantics.




Implementation implications : I could foresee one difficulty but need 
communities opinion
The top label which is 
a special service label will be swapped with peer's service label but only 
after forwarding decision is made.

Partial development : This i am not sure at this point of time, i will 
definitely check with with our product team and get back to you ASAP.

I do not wish to get into a protracted discussion on a proposal that is 
unlikely to be adopted. Independent of your product requirements, a 
standardized solution will need to address this point one way or another.

Acee





With Regards
Anil S N

From: spring [spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] on 
behalf of Acee Lindem (acee) [a...@cisco.com<mailto:a...@cisco.com>]
Sent: Thursday, September 10, 2015 9:46 PM
To: Pushpasis Sarkar; Anil Kumar S N (VRP Network BL); Gaurav agrawal; 
Alexander Vainshtein
Cc: m...@ietf.org<mailto:m...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; Vinod Kumar S 70786
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Hi Pushpasis, Anil,

From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>>
Date: Thursday, September 10, 2015 at 11:42 AM
To: "Anil Kumar S N (VRP Network BL)" 
<anil...@huawei.com<mailto:anil...@huawei.com>>, Gaurav agrawal 
<gaurav.agra...@huawei.com<mailto:gaurav.agra...@huawei.com>>, Alexander 
Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Cc: "m...@ietf.org<mailto:m...@ietf.org>" 
<m...@ietf.org<mailto:m...@ietf.org>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>, Vinod Kumar S 70786 
<v70...@notesmail.huawei.com.cn<mailto:v70...@notesmail.huawei.com.cn>>
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Hi Anil,

Inline again

From: "Anil Kumar S N (VRP Network BL)"
Date: Thursday, September 10, 2015 at 8:56 PM
To: Pushpasis Sarkar, Gaurav agrawal, Alexander Vainshtein
Cc: "m...@ietf.org<mailto:m...@ietf.org>", 
"spring@ietf.org<mailto:spring@ietf.org>", Vinod Kumar S 70786
Subject: RE: [spring] [SPRING] Query related to SR Architecture

Pushpasis,

Thank you again, Please see inline [Anil >>].

Thanks & Regards
Anil S N

“Be liberal in what you accept, and conservative in what you send” - Jon Postel


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pushpasis Sarkar
Sent: 10 September 2015 20:15
To: Anil Kumar S N (VRP Network BL); Gaurav agrawal; Alexander Vainshtein
Cc: m...@ietf.org<mailto:m...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; Vinod Kumar S 70786
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Hi Anil,

From: "Anil Kumar S N (VRP Network BL)"
Date: Thursday, September 10

Re: [spring] [mpls] [SPRING] Query related to SR Architecture

[Acee Lindem (acee)]

Hi Robert,

On Sep 10, 2015, at 2:38 PM, Robert Raszuk 
> wrote:

​Hey Acee,
​

In MPLS, one label is like any other label (except for the first 15 which are 
reserved). I think you are missing a whole lot of context here - you can’t just 
declare a new label type with different semantics.


​That is actually quite incorrect :)  We do declare new semantics for labels 
all the time ... ​

Few examples:

- context label
- entropy label
- sr label
etc…

But the mechanisms for advertising the label semantics as such must be 
specified as well.

Thanks,
Acee



​Cheers,
R​


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

Re: [spring] SRGBs, indexes, and topologies within a domain

[Acee Lindem (acee)]

It appears there are varying opinions on deployment models. A global SID is 
used as an offset into a node’s local SRGB(s) in order to derive the ingress 
label used for the associated prefix (or other construct) for that node. There 
are two opinions on deployment. The first model is that the global SID is, in 
fact, global and you would use a different SID if you want to advertise a 
different segment, i.e., forwarding instruction. The second is that the global 
SID is not really global and maps to a different segment dependent on the 
protocol instance or topology. Of course, I favor the first model but wanted to 
hi-light the point of contention.
Thanks,
Acee

From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on 
behalf of Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net
Date: Tuesday, August 25, 2015 at 7:29 AM
To: Peter Psenak (ppsenak) ppse...@cisco.commailto:ppse...@cisco.com
Cc: Stephane Litkowski 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org, Pushpasis Sarkar 
(psar...@juniper.netmailto:psar...@juniper.net) 
psar...@juniper.netmailto:psar...@juniper.net, Eric C Rosen 
ero...@juniper.netmailto:ero...@juniper.net
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain


Cool ... as long as I can have a freedom to run multiple instances of ISIS (one 
per topology) with different blocks I am happy !

Cheers,
R.

On Aug 25, 2015 1:19 PM, Peter Psenak 
ppse...@cisco.commailto:ppse...@cisco.com wrote:
Robert,

On 8/25/15 13:14 , Robert Raszuk wrote:
Peter,

If on a given node I run OSPF and ISIS and I advertise differe SRGB
block with each of them what is really per node scope

per node means per IGP. Nobody can prevent you to advertise different SRGBs in 
different IGPs.

thanks,
Peter


Each igp thinks it is per node in their understanding of what the node
is, but between them I see no relation at all.

It would be rather a mistake to assue both igp have congruent base
topologies which such condition seems not easy to avoid if you treat
block as something sitting above both of them.

Thx,
R.

On Aug 25, 2015 12:53 PM, Peter Psenak 
ppse...@cisco.commailto:ppse...@cisco.com
mailto:ppse...@cisco.commailto:ppse...@cisco.com wrote:

Robert,

On 8/25/15 11:50 , Robert Raszuk wrote:

So as long you can also configure multiple SRGBs per node the
discussion
is over :)


the discussion is not about advertising multiple SRGBs, but about
the scope of the SRGB advertisement - currently it is a per node.
The fact that you can advertise multiple SRGBs does not change its
scope.

thanks,
Peter



But that perhaps is a topic outside of IETF and one should express
preferences directly with their vendors.

Thx Peter !
R.

On Aug 25, 2015 11:44 AM, Peter Psenak 
ppse...@cisco.commailto:ppse...@cisco.com
mailto:ppse...@cisco.commailto:ppse...@cisco.com
mailto:ppse...@cisco.commailto:ppse...@cisco.com 
mailto:ppse...@cisco.commailto:ppse...@cisco.com wrote:

 On 8/25/15 11:36 , Robert Raszuk wrote:

 Peter,

 In first sentence you say single block in second one
you say
 multiple
 blocks so which one it is  ?


 you can advertise multiple SGRBs per node.

 Peter



 Thx,
 R.

 On Aug 25, 2015 11:25 AM, Peter Psenak
ppse...@cisco.commailto:ppse...@cisco.com 
mailto:ppse...@cisco.commailto:ppse...@cisco.com
 mailto:ppse...@cisco.commailto:ppse...@cisco.com 
mailto:ppse...@cisco.commailto:ppse...@cisco.com
 mailto:ppse...@cisco.commailto:ppse...@cisco.com 
mailto:ppse...@cisco.commailto:ppse...@cisco.com
mailto:ppse...@cisco.commailto:ppse...@cisco.com 
mailto:ppse...@cisco.commailto:ppse...@cisco.com wrote:

  Robert,

  On 8/25/15 11:05 , Robert Raszuk wrote:

  Peter,

  You can partition it in many ways, but the
block is
 just one.

  As you recall mpls architecture does not have such
 limitation.
  You can
  have per interface overlapping label space.

  Likewise to me SRGB blocks for MT or MI do not
need to be
  continuos what
  your earlier suggestion regarding offset would
result with.

  So I think the crux of this entire debate is
this: are we
  allowing non
  continous SRGB pools per node or not (say one per
 topology).


  No matter how many partitions you have, still it's

Re: [spring] SRGBs, indexes, and topologies within a domain

[Acee Lindem (acee)]

Hi Stephane - Why do need to use different label blocks, i.e., for
different topologies? You have two other simpler options:

1. Just allocate SIDs to prefix, mt_id tuples. So if a node has SIDs
[1-10], just allocate a unique SID to each unique combinations of tuple.
2. For a node, allocate ranges of SIDs to a topology rather than
trying to allocate SRGBs. Then the SID would map to whatever the label the
offset correspond to in the local node’s SRGB(s).

Thanks,
Acee 

On 8/25/15, 7:28 PM, spring on behalf of stephane.litkow...@orange.com
spring-boun...@ietf.org on behalf of stephane.litkow...@orange.com wrote:

Hi Peter,

As I already pointed to Les, using an offset creates some holes in index
space that we need to manage when extending a block.

Let's say that we have SRGB [100-199] (to simplify) and you divide your
block in two so you will have topology #1 using [100-149] and topology #2
using [150-199] using an offset of 50.
Now I need to add a 51th node in my network, I cannot use index 51
because it will overlap with topology#2 :(, so I will need to skip
indexes from 51 to 100, and restarts my numbering with index 101. This
management of holes is not automated.

Best Regards,

Stephane

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Tuesday, August 25, 2015 13:18
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Stephane,

On 8/25/15 12:58 , stephane.litkow...@orange.com wrote:
 Hi Peter,

 1. If a new topology is added by use of the MT features of an IGP,
 then a new set of prefix-SIDs must be provisioned.  This seems like
 a major provisioning task.  The alternative would be to have an SRGB
 per topology; then when you add a new topology, you only have one
 quantity to provision (or one per platform perhaps).  I hear some
 hand-waving about how easy it is to provision new prefix-SIDs for
 every new topology, but ...

 I will keep repeating myself that such provisioning can be made
automatic, so the above point is not really convincing to me.

 Could you explain how ? Based on past discussions, it does not seem to
be so easy.

simply by associating an offset and size from SRGP on a per topology
basis.

Example:

SRGB 1600-24000

I would assume that when you start to assign your SIDs for the default
topology, you would not pick random values, but start from the beginning.
So let' assume you are using 16001 to 16500 for nodes in default topology.

Now you need to add a new topology. You configure and offset of 2k for
it, so the advertised SIDs for the new topology would start from 18001.
If we assume that the 2k would be a reasonable size for each topology you
can have 4 topologies with 2k SIDs per topology.

If for whatever reason you run out of the SID space in any topology, you
can configure another offset for those SIDs which do not fit into the
existing range for such topology.

All of the above is internal to the node and no per topology SRGB
advertisement is required. You advertise unique SID on a per prefix and
per topology basis, but you do not need to configure each SID manually.
Al you need to configure is the single prefix SID and per topology
offset/size. It gives you the same simplicity for configuration as per
topology SRGB, but without the need to advertise SRGB per topology.

thanks,
Peter


 Best Regards,

 Stephane



 __
 ___

 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

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[Acee Lindem (acee)]

Hi Rabah,

From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on 
behalf of rabah.gued...@orange.commailto:rabah.gued...@orange.com 
rabah.gued...@orange.commailto:rabah.gued...@orange.com
Date: Wednesday, August 12, 2015 at 4:09 AM
To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, 
Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Stephane 
Litkowski 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Jeff 
Tantsura jeff.tants...@ericsson.commailto:jeff.tants...@ericsson.com, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Les
The discussion that you pointed out does not discuss  the conflicting SRGB 
scenario that I explained,
rather it is about the conflicting index ranges which is another problem.

To clarify :
1) The Index range conflict  result in having two IGP prefixes with same Index 
value.

The SR YANG model configures the node-sids outside the IGPs - 
https://www.ietf.org/id/draft-ietf-spring-sr-yang-00.txt. If you advertise the 
same prefix in multiple protocols in the same topology, it should use the same 
index value. The case where you need to partition the SID space between 
protocols is the exception rather than the rule.


2)SRGB range overlapping  problem happens only when we consider the scenario 
where a SPRING node runs two or more IGPs, and every IGP has its own SRGB,

Unless you have completely separate routing domains with completely separate 
SID spaces, you’d want to use a consistent SRGB across protocols.

Thanks,
Acee



PS As stephane one of the authors of SR-yang said  the consensus is to adopt 
the per-protocol SRGB space option.

Bests,
RABAH.


De : Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Envoyé : mardi 11 août 2015 20:48
À : Pushpasis Sarkar; GUEDREZ Rabah IMT/OLN; LITKOWSKI Stephane SCE/IBNF; Jeff 
Tantsura; spring@ietf.orgmailto:spring@ietf.org
Objet : RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Pushpasis/Rabah –

The conflicting SRGB range issue is neither new nor specific to protocol 
specific SRGBs. There is already a (somewhat lively) discussion going on about 
what to do w conflicting SRGB ranges when received (see attached email).
IMO if you want to discuss this issue it would be better done in the context of 
the attached thread – not this one.

   Les


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pushpasis Sarkar
Sent: Tuesday, August 11, 2015 9:54 AM
To: rabah.gued...@orange.commailto:rabah.gued...@orange.com; LITKOWSKI 
Stephane SCE/IBNF; Jeff Tantsura; spring@ietf.orgmailto:spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Rabah,

Totally agree to your point. And that is why IMO, the configuration module on 
any router MUST NOT allow any of the per-protocol SRGBs to overlap. All the 
per-protcol SRGBs MUST be non-overlapping.

Thanks
-Pushpasis

From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on 
behalf of rabah.gued...@orange.commailto:rabah.gued...@orange.com 
rabah.gued...@orange.commailto:rabah.gued...@orange.com
Date: Tuesday, August 11, 2015 at 8:00 PM
To: LITKOWSKI Stephane SCE/IBNF 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Jeff 
Tantsura jeff.tants...@ericsson.commailto:jeff.tants...@ericsson.com, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

I strongly support option #2

but a Problem may occur in that case, if the per-protocol SRGBs share a 
subSpace.

so let us consider the following example where node N is a SPRING node with two 
SR-IGP instances   SR-OSPF and SR-ISIS running,
if we configure OSPF-SRGB [8000, 1] and ISIS-SRGB [9000, 11000].
actually accepting this configuration may result in the same label for two IGP 
prefixes (EX :  OSPF-Prefix-index 1001 and ISIS-prefix-index 1 will have the 
label 9001)
which get translated into two entries in the forwarding table.

to solve that I suggest to add a new notification of type let's say
“SRGB-collusion-detected “ which will be raised upon the detection of the SRGBs 
collusion

Rabah

De : spring [mailto:spring-boun...@ietf.org] De la part de 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com
Envoyé : vendredi 31 juillet 2015 10:52
À : Jeff Tantsura; spring@ietf.orgmailto:spring@ietf.org
Objet : Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Looks that consensus is for option#2, so let’s move SRGB to protocol 
configuration.


From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com]
Sent: Friday, July 31, 2015 08:04
To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.orgmailto:spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi,

Architecturally I agree – label manager shouldn’t 

Re: [spring] FW: Adoption Call for draft-previdi-6man-segment-routing-header-07

[Acee Lindem (acee)]

You guys release that you should be supporting on the 6man list
i...@ietf.org. These are all going to ipv6-boun...@ietf.org.
Acee

On 8/7/15, 11:45 AM, spring on behalf of Jeff Tantsura
spring-boun...@ietf.org on behalf of jeff.tants...@ericsson.com wrote:

Yes/support

Cheers,
Jeff




-Original Message-
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Bob Hinden
Sent: Saturday, August 01, 2015 9:12 PM
To: IPv6 List
Cc: Bob Hinden
Subject: Adoption Call for
draft-previdi-6man-segment-routing-header-07

This message starts a two week 6MAN call on adopting:

 Title : IPv6 Segment Routing Header (SRH)
 Authors   : S. Previdi, C. Filsfils, B. Field, I. Leung, E. Aries,
 E. Vyncke, D. Lebrun
 Filename  : draft-previdi-6man-segment-routing-header-07
 Pages : 16
 Date  : 2015-07-20

 
http://datatracker.ietf.org/doc/draft-previdi-6man-segment-routing-head
e
r
/

as a working group item. Substantive comments and statements of support
for adopting this document should be directed to the mailing list.
Editorial suggestions can be sent to the authors.  This adoption call
will end on August 15, 2015.

Regards,

Bob Hinden  Ole Trøan




___
_
_
_
___

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

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

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[Acee Lindem (acee)]

Hi Pushpasis,

On Jul 30, 2015, at 2:22 AM, Pushpasis Sarkar 
psar...@juniper.netmailto:psar...@juniper.net wrote:

HI Acee,

From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com
Date: Thursday, July 30, 2015 at 2:03 AM
To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com
Cc: Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Stephane 
Litkowski 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org, Shraddha Hegde 
shrad...@juniper.netmailto:shrad...@juniper.net, Uma Chunduri 
uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Pushpasis Sarkar 
psar...@juniper.netmailto:psar...@juniper.net, Aissaoui, Mustapha 
(Mustapha) 
mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com,
 Hannes Gredler han...@juniper.netmailto:han...@juniper.net
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang


On Jul 29, 2015, at 6:28 PM, Les Ginsberg (ginsberg) 
ginsb...@cisco.commailto:ginsb...@cisco.com wrote:

Robert -

From: rras...@gmail.commailto:rras...@gmail.com [mailto:rras...@gmail.com] On 
Behalf Of Robert Raszuk
Sent: Wednesday, July 29, 2015 2:45 PM
To: Les Ginsberg (ginsberg)
Cc: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; Uma 
Chunduri; Aissaoui, Mustapha (Mustapha); 
spring@ietf.orgmailto:spring@ietf.org; Shraddha Hegde 
(shrad...@juniper.netmailto:shrad...@juniper.net); Pushpasis Sarkar 
(psar...@juniper.netmailto:psar...@juniper.net); Hannes Gredler 
(han...@juniper.netmailto:han...@juniper.net)
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

 ​
This makes no sense to me operationally or architecturally.

Fundamentally I fully agree with you.


However architecturally:

However at least looking at group of folks who claim that it is impossible to 
get same SRGB block in *any* network between two or more vendors  I think 
Stephane's intention would be to at least get it per one protocol even if 
platform wide the intersecting pool may be mission impossible.

[Les:] This is an unrelated issue. Placing SRGB in global context does not mean 
all routers have to have the same SRGB. There is no controversy here.


and now operationally:

Another reason would be idea of dual overlapping SRGBs perhaps quite useful 
during migrations between protocols where the exact same SRGB is set on both 
then just based on admin distance one vs the other protocol is chosen. While a 
standard practice in protocol migrations not sure if anyone looked at that from 
SR perspective.
[Les:] Not sure what you are trying to say. If the two SRGBs are the same – why 
do we need to configure them per protocol?
If the two SRGBs are not the same, other routers in the network have  no idea 
which protocol is going to win on your box. So your neighbor has no idea 
whether it should use the SRGB advertised by OSPF or the SRGB advertised by 
IS-IS.


Actually, if the same prefix in the same topology is advertised by two 
protocols, I would think that the SID should map to the same label. I see no 
advantage at all in having separate labels.
[Pushpasis] We are talking about the MPLS transit label for the destination FEC 
here. Like RSVP and LDP, in MPLS data plane today, the FEC maybe same but the 
transit label allocated by each protocol are different.

This is not  a good analogy. LDP normally follows the IP routed path while RSVP 
is used to set up a TE engineered path.


Similarly for SR mapped to MPLS data plane the transit label allocated by ISIS 
and OSPF for the same destination FEC should be different. Hence the need of 
per-protocol SRGB.

This is a circular argument. Why would the IP unicast routed path require a 
different label for ISIS vs OSPF?

Acee




Acee




   Les


Cheers,
R.


On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) 
ginsb...@cisco.commailto:ginsb...@cisco.com wrote:
Stephane –

What is the requirement to have a per-protocol SRGB config?
​​
This makes no sense to me operationally or architecturally.

(I am not talking about what may or may not have been implemented by vendors – 
the YANG model should be architecturally correct)

   Les

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


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

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[Acee Lindem (acee)]

Hi Pushpasis,

On Jul 30, 2015, at 11:11 AM, Pushpasis Sarkar 
psar...@juniper.netmailto:psar...@juniper.net wrote:

Hi Acee,

From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com
Date: Thursday, July 30, 2015 at 8:37 PM
To: Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net
Cc: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Les 
Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert 
Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Aissaoui, Mustapha 
(Mustapha) 
mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com,
 Stephane Litkowski 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org, Uma Chunduri 
uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Hannes Gredler 
han...@juniper.netmailto:han...@juniper.net
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Pushpasis,

On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar 
psar...@juniper.netmailto:psar...@juniper.net wrote:

Hi Acee,

From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com
Date: Thursday, July 30, 2015 at 7:18 PM
To: Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net
Cc: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Les 
Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert 
Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Aissaoui, Mustapha 
(Mustapha) 
mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com,
 Stephane Litkowski 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org, Uma Chunduri 
uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Hannes Gredler 
han...@juniper.netmailto:han...@juniper.net
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Robert, Pushpasis, Shraddha,

I guess I don’t understand why this gives you any operational advantage when 
you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact, if 
you are using separate label spaces it will make migration more difficult and 
you will have to migrate your routing domain in shot rather than incrementally.
[Pushpasis] All routers will program both transit mpls labels and create two 
parallel MPLS data planes well before the last step when all the ingress router 
will be instructed to switch traffic onto the new MPLS data plane (programmed 
by the new protocol) by changing the admin distance. That way the migration 
shall become seamless. And then once all ingreess routers has been swicthed to 
the new protocol and new MPLS dataplane, the old protocol and old MPLS data 
plane can be just removed from all the routers. Hope it is clear now…

Normally only the protocol with the lower preference or admin distance would 
install a route to a particular prefix (including the label) into the RIB/LIB 
for the base IP unicast topology. I guess you are envisioning separate RIBs per 
protocol as well?
[Pushpasis] What you are saying is true for the IP/V6—MPLS route in RIB/FIB on 
ingress routers. It is NOT TRUE for MPLS transit routes in LFIB. In MPLS 
architecture no two protocols installs the same label in LFIB. Each protocol 
(LDP/RSVP) uses different transit labels for the same destination IP/V6 FEC.

That is one way to implement it but it makes more sense for the IGP label 
imposition and label stitching to both be dependent on the route being 
preferred.
However, in another conversation I have been convinced that the network 
consolidation use case could benefit from configuration of per-protocol SRGB so 
I’m no longer opposed to this being a feature of the YANG model.

Thanks,
Acee





Thanks,
Acee





Thanks,
Acee

On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar 
psar...@juniper.netmailto:psar...@juniper.net wrote:

+1

From: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net
Date: Thursday, July 30, 2015 at 8:58 AM
To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, 
Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net
Cc: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Uma 
Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, 
Aissaoui, Mustapha (Mustapha) 
mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com,
 spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org, Pushpasis Sarkar 
psar...@juniper.netmailto:psar...@juniper.net, Hannes Gredler 
han...@juniper.netmailto:han...@juniper.net
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang


[Shraddha] route preference is local to router and the neighbor never knows 
what the other is going to choose.  If there are inconsistencies in two 
protocols, there are going to be loops

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[Acee Lindem (acee)]

On Jul 29, 2015, at 6:28 PM, Les Ginsberg (ginsberg) 
ginsb...@cisco.commailto:ginsb...@cisco.com wrote:

Robert -

From: rras...@gmail.commailto:rras...@gmail.com [mailto:rras...@gmail.com] On 
Behalf Of Robert Raszuk
Sent: Wednesday, July 29, 2015 2:45 PM
To: Les Ginsberg (ginsberg)
Cc: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; Uma 
Chunduri; Aissaoui, Mustapha (Mustapha); 
spring@ietf.orgmailto:spring@ietf.org; Shraddha Hegde 
(shrad...@juniper.netmailto:shrad...@juniper.net); Pushpasis Sarkar 
(psar...@juniper.netmailto:psar...@juniper.net); Hannes Gredler 
(han...@juniper.netmailto:han...@juniper.net)
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

 ​
This makes no sense to me operationally or architecturally.

Fundamentally I fully agree with you.


However architecturally:

However at least looking at group of folks who claim that it is impossible to 
get same SRGB block in *any* network between two or more vendors  I think 
Stephane's intention would be to at least get it per one protocol even if 
platform wide the intersecting pool may be mission impossible.

[Les:] This is an unrelated issue. Placing SRGB in global context does not mean 
all routers have to have the same SRGB. There is no controversy here.


and now operationally:

Another reason would be idea of dual overlapping SRGBs perhaps quite useful 
during migrations between protocols where the exact same SRGB is set on both 
then just based on admin distance one vs the other protocol is chosen. While a 
standard practice in protocol migrations not sure if anyone looked at that from 
SR perspective.
[Les:] Not sure what you are trying to say. If the two SRGBs are the same – why 
do we need to configure them per protocol?
If the two SRGBs are not the same, other routers in the network have  no idea 
which protocol is going to win on your box. So your neighbor has no idea 
whether it should use the SRGB advertised by OSPF or the SRGB advertised by 
IS-IS.


Actually, if the same prefix in the same topology is advertised by two 
protocols, I would think that the SID should map to the same label. I see no 
advantage at all in having separate labels.

Acee




   Les


Cheers,
R.


On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) 
ginsb...@cisco.commailto:ginsb...@cisco.com wrote:
Stephane –

What is the requirement to have a per-protocol SRGB config?
​​
This makes no sense to me operationally or architecturally.

(I am not talking about what may or may not have been implemented by vendors – 
the YANG model should be architecturally correct)

   Les

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

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

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[Acee Lindem (acee)]

I strongly prefer option 1. The purpose of the SRGB range is to allow devices 
in the segment routing domain to use different MPLS label ranges for segment 
routing. This is necessary either due to the devices having allocated MPLS 
label ranges for other purposes (e.g., LDP or static LSPs) or the devices not 
supporting the full MPLS label range. SRGB is not meant to be used to allocate 
unique label ranges to various protocols or purposes.
Thanks,
Acee

From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on 
behalf of Stephane Litkowski 
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com
Date: Wednesday, July 22, 2015 at 7:19 PM
To: spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi WG,

In the current version of the config Yang model for SR, the SRGB list is 
configured at SR top level, so it is agnostic to the routing protocol.
We had some comment in Dallas on difficulties that having common label range 
shared between protocols could lead to.
During discussion in our design team, some point was also raised on routing 
protocol migrations that may be safer using a per protocol SRGB (so 
configuration the SRGB at IGP level rather than globally).

We would like to hear from the WG about the preference and arguments for both 
approaches :
Approach 1) keep SRGB configuration at top level, and so routing protocols will 
share the same label space (today proposal)
Approach 2) move SRGB configuration to protocols, each routing protocol manages 
its own label space.

Thanks to provide your feedback in order to solve this issue and have a 
consensus.


[Orange logo]http://www.orange.com/

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 
https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
mobile: +33 6 37 86 97 52 
https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20
stephane.litkow...@orange.commailto:stephane.litkow...@orange.com



_

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] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop

[Acee Lindem (acee)]

I support WG adoption as there is a strong requirement for
interoperability. 
Thanks,
Acee 

On 7/22/15, 3:17 PM, spring on behalf of John G.Scudder
spring-boun...@ietf.org on behalf of j...@juniper.net wrote:

Dear WG,

As we discussed at our meeting yesterday, working group adoption has been
requested for draft-filsfils-spring-segment-routing-ldp-interop. Please
reply to the list with your comments, including although not limited to
whether or not you support adoption. Non-authors are especially
encouraged to comment.

In consideration of the fact that a number of WG calls are going on
concurrently, we will end the call on August 31, 2015.

Authors, please indicate whether you are aware of any relevant IPR and if
so, whether it has been disclosed. Also, the length of the author list
for this document greatly exceeds the maximum recommended. Assuming the
document is adopted, the authors should be prepared to correct this when
submitting as a WG document, ideally by reducing the list to simply the
active editor(s) and making use of the contributors section for the
full list.

Thanks,

--Bruno and John

P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to.
___
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

Re: [spring] 答复: 答复: New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path

[Acee Lindem (acee)]

Hi Robin,

From: Lizhenbin lizhen...@huawei.commailto:lizhen...@huawei.com
Date: Monday, January 26, 2015 at 6:11 AM
To: Acee Lindem a...@cisco.commailto:a...@cisco.com, Robert Raszuk 
rob...@raszuk.netmailto:rob...@raszuk.net
Cc: m...@ietf.orgmailto:m...@ietf.org 
m...@ietf.orgmailto:m...@ietf.org, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org
Subject: 答复: [spring] 答复: New Comments on Segment Routing(4): Challenge of 
Route Dependency for SR-BE Path


Hi Acee,

I don't think my proposed issues is the same case as you proposed. I think your 
proposed case is like forwarding agency or IGP short-cut using tunnel as the 
interface to hide the MPLS from the OSPF.  My case is the SR-BE path in which 
OSPF is like LDP as one MPLS control protocol to loop up the route to determine 
the outgoting interface and the nexthop for the label mapping advertised by 
OSPF's self instead of hiding the label in the tunnel.

Right - and my point is that normally OSPF would only consider OSPF routes in 
this case.

Thanks,
Acee







Regards,

Robin










发件人: Acee Lindem (acee) [a...@cisco.commailto:a...@cisco.com]
发送时间: 2015年1月22日 22:15
收件人: Lizhenbin; Robert Raszuk
抄送: m...@ietf.orgmailto:m...@ietf.org; spring@ietf.orgmailto:spring@ietf.org
主题: Re: [spring] 答复: New Comments on Segment Routing(4): Challenge of Route 
Dependency for SR-BE Path

Hi Robin,
I don’t know about other IGP implementations but the ones I’ve worked on do not 
resolve routes recursively (unlike LDP or BGP which do).  There are cases where 
OSPF runs over a tunnel but in these cases the OSPF interface is either up or 
down dependent on the tunnel status. Hence, I think the issue you’ve raised 
regarding protocol synchronization is a moot point.
Thanks,
Acee

From: Lizhenbin lizhen...@huawei.commailto:lizhen...@huawei.com
Date: Thursday, January 22, 2015 at 6:08 AM
To: Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net
Cc: m...@ietf.orgmailto:m...@ietf.org 
m...@ietf.orgmailto:m...@ietf.org, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org
Subject: [spring] 答复: New Comments on Segment Routing(4): Challenge of Route 
Dependency for SR-BE Path


Hi Robert,

Please refer to my inline '[Robin]'.



Regards,

Robin




发件人:rras...@gmail.commailto:rras...@gmail.com 
[rras...@gmail.commailto:rras...@gmail.com] 代表 Robert Raszuk 
[rob...@raszuk.netmailto:rob...@raszuk.net]
发送时间: 2015年1月22日 15:46
收件人: Lizhenbin
抄送: spring@ietf.orgmailto:spring@ietf.org; m...@ietf.orgmailto:m...@ietf.org
主题: Re: [spring] New Comments on Segment Routing(4): Challenge of Route 
Dependency for SR-BE Path

Hi Robin,

I think your question is not applicable to SR architecture.

The right SR analogy to LDP would *NOT* be hop by hop LDP like in your example, 
but targeted (aka directed) LDP session.
[Robin] I could not understand your point. No matter T-LDP or local LDP, they 
should lookup in the RIB/FIB to determine if the label mapping is active.
In those how to get to FEC's address is just regular lookup in the RIB/FIB 
(global or vrf depends on use case) and it does not matter what protocol src 
installed the route.
[Robin] As what you described, could I understand you means for the SR based on 
a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determine if the 
label binding is up? If so, there will be the two route dependency change 
issues I proposed for the OSPF. Why do you think they are not applicable to SR?


Also note that like in most LDP case SR labels or IDs are global so 
regardless on which interface packet arrives (within given topology in case of 
mt) the lookup result will be identical.

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin 
lizhen...@huawei.commailto:lizhen...@huawei.com wrote:

Hi all authors of segment routing,



This is the fourth comments.



For LDP, when search route for the destination address which is the FEC of the 
label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS, 
BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is 
advertised through OSPF, what type

of routes should the label mapping depend on when setup the SR-BE path?



I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.



I don't think it should be the Option 1. For example, we configure static 
routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the 
node. If the static route has higher
priority than the OSPF and the SID/label is advertised by OSPF depends on OSPF 
routes, there will be the

inconsistency between the SR-BE path and the route path.



If the option 2 is adopted, it cannot be assumed that the label mapping and the 
route are in the same LSDB which

can be easily synchronized

Re: [spring] 答复: New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path

[Acee Lindem (acee)]

Hi Robin,
I don’t know about other IGP implementations but the ones I’ve worked on do not 
resolve routes recursively (unlike LDP or BGP which do).  There are cases where 
OSPF runs over a tunnel but in these cases the OSPF interface is either up or 
down dependent on the tunnel status. Hence, I think the issue you’ve raised 
regarding protocol synchronization is a moot point.
Thanks,
Acee

From: Lizhenbin lizhen...@huawei.commailto:lizhen...@huawei.com
Date: Thursday, January 22, 2015 at 6:08 AM
To: Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net
Cc: m...@ietf.orgmailto:m...@ietf.org 
m...@ietf.orgmailto:m...@ietf.org, 
spring@ietf.orgmailto:spring@ietf.org 
spring@ietf.orgmailto:spring@ietf.org
Subject: [spring] 答复: New Comments on Segment Routing(4): Challenge of Route 
Dependency for SR-BE Path


Hi Robert,

Please refer to my inline '[Robin]'.



Regards,

Robin




发件人: rras...@gmail.commailto:rras...@gmail.com 
[rras...@gmail.commailto:rras...@gmail.com] 代表 Robert Raszuk 
[rob...@raszuk.netmailto:rob...@raszuk.net]
发送时间: 2015年1月22日 15:46
收件人: Lizhenbin
抄送: spring@ietf.orgmailto:spring@ietf.org; m...@ietf.orgmailto:m...@ietf.org
主题: Re: [spring] New Comments on Segment Routing(4): Challenge of Route 
Dependency for SR-BE Path

Hi Robin,

I think your question is not applicable to SR architecture.

The right SR analogy to LDP would *NOT* be hop by hop LDP like in your example, 
but targeted (aka directed) LDP session.
[Robin] I could not understand your point. No matter T-LDP or local LDP, they 
should lookup in the RIB/FIB to determine if the label mapping is active.
In those how to get to FEC's address is just regular lookup in the RIB/FIB 
(global or vrf depends on use case) and it does not matter what protocol src 
installed the route.
[Robin] As what you described, could I understand you means for the SR based on 
a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determine if the 
label binding is up? If so, there will be the two route dependency change 
issues I proposed for the OSPF. Why do you think they are not applicable to SR?


Also note that like in most LDP case SR labels or IDs are global so 
regardless on which interface packet arrives (within given topology in case of 
mt) the lookup result will be identical.

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin 
lizhen...@huawei.commailto:lizhen...@huawei.com wrote:

Hi all authors of segment routing,



This is the fourth comments.



For LDP, when search route for the destination address which is the FEC of the 
label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS, 
BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is 
advertised through OSPF, what type

of routes should the label mapping depend on when setup the SR-BE path?



I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.



I don't think it should be the Option 1. For example, we configure static 
routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the 
node. If the static route has higher
priority than the OSPF and the SID/label is advertised by OSPF depends on OSPF 
routes, there will be the

inconsistency between the SR-BE path and the route path.



If the option 2 is adopted, it cannot be assumed that the label mapping and the 
route are in the same LSDB which

can be easily synchronized. There are two challenges:
1. The direct effect for the OSPF is that at the beginning it just downloads it 
routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing to 
SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BGP, 
etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the possible 
risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP sync? Or do you just think 
they are rare cases which should not

 be taken into account? Hope you have had enough analysis on this issue.



According to the comments on the dependency, I hope you could specify clearly 
in the appropriate draft of segment

routing as to follows questions for SR-BE path which is helpful for 
interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection resulte from 
multiple sources.







Regards,
Robin



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


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

Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02

[Acee Lindem (acee)]

This is my preference for the protocol extension drafts.
Thanks,
Acee 

On 8/1/14, 3:48 PM, Stefano Previdi (sprevidi) sprev...@cisco.com
wrote:

my point is that description of use cases should be on a
separate document in order to avoid replication of text
between isis and ospf drafts.

Protocol extensions drafts should be focused on bits/bytes
to be carried by the protocol.

I think there's agreement on this.

s.


On Aug 1, 2014, at 8:57 PM, Chris Bowers wrote:

 I disagree.  The proposed text contains four Binding TLV usage examples
which are not qualitatively different from the two usage examples
already included in section 2.4.3 of
draft-ietf-isis-segment-routing-extensions-02.  Additional usage
examples are needed to clarify how the TLVs and sub-TLVs defined in this
document should be used, without ambiguity.
 
 As an example of the lack of clarity in the current text,
draft-ietf-isis-segment-routing-extensions-02 contains two different
sub-TLVs for specifying SID/Label values in the Binding TLV. The two
options are the SID/Label Sub-TLV (section 2.3) and the Prefix-SID
Sub-TLV (section 2.1).  The current text does not clearly explain under
what circumstances the two different sub-TLVs should be used in the
Binding TLV.   The proposed text makes the usage clear by means of
examples.   
 
 Chris
 
 -Original Message-
 From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
 Sent: Friday, August 01, 2014 1:54 AM
 To: Uma Chunduri
 Cc: Chris Bowers; isis...@ietf.org; spring@ietf.org
 Subject: Re: [Isis-wg] comment on
draft-ietf-isis-segment-routing-extensions-02
 
 Uma,
 
 I agree.
 
 I think we also explicitly stated this during our meeting in Toronto
(from the minutes):
 
   
   Uma: Needed to reference use cases in Hannes' draft.
   Hannes: Perhaps what we could do is add some practical examples for
   RSVP, BGP, and LDP LSPs binding. Not formal use cases.
   Stefano: Would rather not go into applications in this ISIS draft.
   Peter Psenak: Should go into a separate document that could be
   referenced from both ISIS and OSPF.
   Alia Atlas: There is a SPRING WG for such a document.
   ---
 
 Now, note that:
   draft-filsfils-spring-segment-routing
   draft-filsfils-spring-segment-routing-ldp-interop
 
 describe the use case of the SR Mapping Server that is implemented
using the Binding TLV.
 
 As you suggested, Hannes drafts can be combined so to produce a
use-case document (in spring) for the Binding TLV RSVP-based use-cases.
 
 
 s.
 
 
 On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote:
 
 [CC'ed Spring WG]
 
 I agree with what Chris said below in principle. But all this should
not be obviously part of ISIS/IGP extensions WG documents..
 
 Use  cases for binding TLVs are explained in great details in 2 key
 documents (had to shuffle through to get here) -
 
 1.   
http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-0
5
 2.   http://tools.ietf.org/html/draft-gredler-spring-mpls-06
 
 IMO, both are very useful documents.
 It would be good  to combine both of these and publish as a spring 
document and eventually it should progress there.
 AFAICT, Both ISIS and OSPF should refer the same eventually to get
more clarity and use of binding TLVs described currently.
 
 --
 Uma C.
 
 From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Chris
 Bowers
 Sent: Thursday, July 31, 2014 2:42 PM
 To: isis...@ietf.org
 Subject: [Isis-wg] comment on
 draft-ietf-isis-segment-routing-extensions-02
 
 All,
 
 The current text of draft-ietf-isis-segment-routing-extensions-02 does
not clearly explain the usage of the Binding TLV for advertising LSPs
created using other protocols.  I would like to propose the following
text to be included as section 2.5 .
 
 Thanks,
 Chris
 
 
 
 2.5 Binding TLV usage examples
 
 This section gives examples of using the Binding TLV to advertise
SID/label bindings associated with RSVP-TE, LDP, and BGP
labeled-unicast LSPs.  It also includes an example of advertising a
context-id for egress node protection.  All of the examples assume that
the Binding TLV weight=1 and metric=100.
 
 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV
 
 Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with
router-id=10.4.4.4, with ER0 = (192.1.2.2 [strict], 192.2.3.2 [strict],
192.3.4.2 [strict]). R1 can advertise a locally significant label
binding for this LSP (with label value=1099)  using the following
values and sub-TLVs in the Binding TLV.
 
 Binding-TLV: F-bit=0, M-bit=0, weight=1, range=1, prefix length=32,
 FEC prefix=10.4.4.4 SID/Label Sub-TLV: label=1099 ERO Metric sub-TLV:
 metric=100
 IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.1.2.2
 IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.2.3.2
 IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.3.4.2
 
 2.5.2 Advertising an LDP