Subject: [spring] Mail regarding draft-ietf-spring-conflict-resolution

From: Shraddha Hegde <[email-masked]>
Date: Wed, 3 May 2017 16:57:45 +0000

Hi Authors,

When there are multiple anycast IP addresses assigned to different nodes and one or more nodes
do not advertise a Prefix SID for that anycast address but other nodes advertise a prefix-sid, there is a possibility
of different implementations behaving differently with respect to programming the labelled routes.

 This scenario should be considered as a prefix conflict and the behavior should be addressed in the draft.
I suggest to update section 3.2.1 with the relevant text to describe the behavior.

Rgds
Shraddha

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 May 2017 18:16:59 +0000

Shraddha -

There is a misunderstanding on your part. It would be good if you read Section 3.3.8.  Guaranteeing Database Consistency again.

In short, it does not matter whether you do or do not advertise a prefix SID for a prefix which you own. What matters is that all routers populate the mapping entry database consistent w Section 3.3.8 and that each router applies the conflict resolution rules in a consistent manner. Then all routers will be using the same prefix/SID pair in forwarding.

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Wednesday, May 03, 2017 9:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: Mail regarding draft-ietf-spring-conflict-resolution

Hi Authors,

Rgds
Shraddha

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 4 May 2017 05:16:11 +0000

Les,

>From what you describe in section 3.3.8, all the SIDs attached to prefixes are fed into the database.
The example I am talking about,

1.prefix 1.1.1.1 advertised from node A with no SID
2.Prefix 1.1.1.1 advertised from node B with SID 10
3. Prefix 1.1.1.1 advertised from node C with SID 10

The advertisements 2 and 3 are fed into the mapping database and 1 isn't.

The conflict resolution does not detect any conflict with the above advertisements and
For prefix 1.1.1.1 /SID 10 is chosen.
All this is fine but the problem is in programming the forwarding plane.

Lets say for a certain node E in the network node A is the nexthop for 1.1.1.1.
How would node E program its forwarding plane?

Node E should recognize the conflict between node A, Node B and C and program the
SID 10 with a pop and forward instead of looking into the P and E flags of the SID 10?

This is good enough detail, that should be explained in the draft instead of leaving it to the
Imagination of implementers.

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Wednesday, May 3, 2017 11:47 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution

Shraddha -

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Wednesday, May 03, 2017 9:58 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Mail regarding draft-ietf-spring-conflict-resolution

Hi Authors,

Rgds
Shraddha

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 May 2017 18:35:21 +0000

Shraddha -

First, there is no SID conflict here. There is therefore nothing for the conflict resolution draft to discuss.

Let's look at your scenario more detail. To do so let's use the following simple topology:

       --------------A
  /
G-----------------B
  \
     ----------------C

Using your example w addition of P/E flag settings in prefix-sid advertisement (using IS-IS naming convention).
For simplicity assume all nodes have the default SRGB (16000 - 23999).

1.prefix 1.1.1.1 advertised from node A with no SID
2.Prefix 1.1.1.1 advertised from node B with SID 10  P flag = 0 E flag = 0
3. Prefix 1.1.1.1 advertised from node C with SID 10 P flag = 1  E flag = 0

Using procedures defined in draft-ietf-spring-conflict-resolution all nodes in the network will use SID 10 when forwarding traffic to 1.1.1.1. The question is what should the penultimate next hop router do when forwarding a packet to each of the owning nodes?

When G forwards the packet to B, PHP is indicated, so G will POP.
When G forwards the packet to C, UHP is indicated and E flag is 0, so G will send the packet with outgoing label 16010.

When G forwards the packet to A, because A has not advertised the prefix-SID (but is SR capable) we do not know whether it wants PHP or not - so we have to make an assumption.
Default MPLS behavior is to assume PHP.
If A does not want PHP then it would have to advertise the prefix SID so it could specify desired behavior using P/E flags.

Note that this same situation can occur if the mapping server is used as a global provisioning tool. In such a case no prefix-SIDs need be advertised in prefix reachability advertisements - all SIDs are advertised by SRMS advertisements which do not include P/E flags.

Historically,  MPLS implementations have chosen a default behavior (equivalent to P and E flags = 0). Some implementations provide knobs to override this behavior.

If your concern is that there is not an explicit definition of default PHP/Explicit NULL behavior, then I think this needs to be directed at the MPLS WG. I do not claim to be an MPLS expert, but I have found these references:

RFC 3036 Section 6

"-  Section 2.16 of the MPLS architecture [RFC3031] requires that
         the initial label distribution protocol negotiation between
         peer LSRs enable each LSR to determine whether its peer is
         capable of popping the label stack.  This version of LDP
         assumes that LSRs support label popping for all link types
         except ATM and Frame Relay.  A future version may specify means
         to make this determination part of the session initiation
         negotiation."

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Wednesday, May 03, 2017 10:16 PM
To: Les Ginsberg (ginsberg); [email-masked]
Cc: [email-masked]
Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution

Les,

Rgds
Shraddha

To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Shraddha -

   Les

Hi Authors,

Rgds
Shraddha

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 5 May 2017 05:01:57 +0000

Les,

The issues we are discussing here are specific to Segment Routing and SPRING is the right
WG to address this. The problem here is not about standardizing what is the default
PHP behavior, it is about the scenarios when this default behavior assumption need to be applied.

The problem doesn't get solved by applying default PHP behavior in all cases.
Assume 1.1.1.1 in the example below is a redistributed prefix from another ISIS Level. In that
case  the pop and forward will cause the service labels to get exposed at A which
would cause black-holing or misrouting.

These are issues caused by config errors and IMO conflict resolution draft is the right place
to describe these cases and the solutions so that all vendors have consistent behaviours.

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, May 5, 2017 12:05 AM
To: Shraddha Hegde <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution

Shraddha -

       --------------A
  /
G-----------------B
  \
     ----------------C

RFC 3036 Section 6

   Les

To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>

Les,

Rgds
Shraddha

Shraddha -

   Les

Hi Authors,

Rgds
Shraddha

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 5 May 2017 07:22:47 +0000

Shraddha -

I say again - there is no conflict and there is no config error.

Let's use another example which does NOT involve anycast.

       --------------A (1.1.1.1)
  /
G-----------------B (1.1.1.2)
  \
     ----------------C(1.1.1.3)

NO SIDS are locally configured on any routers because the operator has chosen to use SRMS as a global provisioning tool.
Therefore none of the prefix reachability advertisements include a SID.

SRMS (say advertised by some node "F" ) advertises the following:

1.1.1.1/32 100 range 3
SRMS advertisements do not support P/E flags.

When G forwards the following packets it has to make a decision as to whether to do PHP, UHP, EXPLICIT_NULL:

1.1.1.1    to A

1.1.1.2    to B

1.1.1.3    to C

But there is no advertisement of P/E for any of the destinations. It must follow a default behavior.

If you think there is a problem here, please clearly state what it is and what you think should be done about it.

But whatever you think it might be, this has nothing to do with SID conflict resolution - which is defining a way to resolve advertised Prefix Conflicts/SID Conflicts as defined in Section 3.2 of the draft.

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Thursday, May 04, 2017 10:02 PM
To: Les Ginsberg (ginsberg); [email-masked]
Cc: [email-masked]
Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution

Les,

Rgds
Shraddha

Shraddha -

       --------------A
  /
G-----------------B
  \
     ----------------C

RFC 3036 Section 6

   Les

Les,

Rgds
Shraddha

Shraddha -

   Les

Hi Authors,

Rgds
Shraddha

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 8 May 2017 08:39:06 +0000

Les,

The use-case you are describing here is SRMS advertisements and there is no problem in handling SRMS
advertisements. There is a special indication in the protocol messages to indicate it is an SRMS advertisement
and it is documented in ISIS and OSPF drafts in detail, how to handle the scenario.

You are suggesting to use the same procedures to handle the case of anycast-SIDs where prefix advertisements aren't
accompanied by a SID advertisements for some of the prefixes.
This procedure does work for anycast-SIDs and I suggest you to add the text to the
draft to standardize. I believe conflict resolution draft is the best place to add it.
Below is my suggested text for the draft.

"Section 3.2.3 Anycast SIDs
[SR-ARCH] defines anycast SIDs which is used for a number of use-cases.
When there are multiple nodes which advertise same anycast prefix, it is possible that
one of the nodes does not advertise a SID for the prefix. This discrepancy
is not detected by the conflict resolution procedure as the conflict resolution database
takes the prefix-SID mappings as input and this particular  case does not have
prefix-SID mapping.

The forwarding plane follows IP routing and so nodes in the network MAY point to a
node which does not advertise a SID. This situation is similar to an SRMS advertisement
where prefix reachability advertisements from a node does not include a SID advertisement for the prefix.
The route programming for such anycast SIDs should follow the PHP procedures as described in,
[SR-ISIS] and [SR-OSPF] for an SRMS advertisement."

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, May 5, 2017 12:53 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution

Shraddha -

1.1.1.1/32 100 range 3

1.1.1.1    to A

1.1.1.2    to B

1.1.1.3    to C

   Les

Les,

Rgds
Shraddha

Shraddha -

       --------------A
  /
G-----------------B
  \
     ----------------C

RFC 3036 Section 6

   Les

Les,

Rgds
Shraddha

Shraddha -

   Les

Hi Authors,

Rgds
Shraddha

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 8 May 2017 22:12:29 +0000

Shraddha -

We are still not on the same page.

The text you mention as regards handling SRMS advertisements in the IGP drafts (e.g. Section 2.4.5.2 in https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-12.txt ) is discussing how one determines if the advertiser of the prefix is also the owner of the prefix. This is necessary to determine if a node is or is not the penultimate nexthop.

The question I believe you are raising is - once a node has determined that it IS the penultimate nexthop - how does it determine whether it should do PHP/UHP and/or use EXPLICIT_NULL.

The point I have made below is that in the absence of a prefix_sid advertisement you do not have explicit settings for P/E bits and therefore have to rely on a default behavior. This is true whenever you have a SID for a prefix but you do not have a prefix-SID advertisement from the originating node. AS we have discussed below this can happen when the SID is advertised solely in SRMS advertisements or (in the case of anycast) when a SID is advertised by a subset of the nodes supporting the anycast address.

This is NOT the subject of the Conflict Resolution draft - so no text belongs there. And I am not convinced anything needs to be said about this.

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Monday, May 08, 2017 1:39 AM
To: Les Ginsberg (ginsberg); [email-masked]
Cc: [email-masked]
Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution

Les,

Rgds
Shraddha

Shraddha -

1.1.1.1/32 100 range 3

1.1.1.1    to A

1.1.1.2    to B

1.1.1.3    to C

   Les

Les,

Rgds
Shraddha

Shraddha -

       --------------A
  /
G-----------------B
  \
     ----------------C

RFC 3036 Section 6

   Les

Les,

Rgds
Shraddha

Shraddha -

   Les

Hi Authors,

Rgds
Shraddha

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 10 May 2017 10:27:07 -0400

On 5/4/2017 2:35 PM, Les Ginsberg (ginsberg) wrote:

> When G forwards the packet to A, because A has not advertised the 
> prefix-SID (but is SR capable) we do not know whether it wants PHP or 
> not – so we have to make an assumption.
>

I'm not sure why you think there is such a thing as "default MPLS 
behavior" in this regard.  In conventional MPLS, when a node advertises 
the binding of a label to a FEC, PHP will not occur unless the 
advertised label is Implicit NULL.   If you advertise a different label, 
you don't get PHP.

If there were any such thing as a default behavior for MPLS, it wouldn't 
make any sense for PHP to be the default behavior.   You can only 
advertise Implicit NULL if you know that the packet can be properly 
processed after the top label is popped off.  Whether PHP will give the 
right result is application-specific.  So if there were a default 
behavior, it would have to be "don't do PHP".  But of course MPLS has no 
need of such a default behavior, because each node advertises its own 
labels.

Since the segment routing architecture allows cases where you don't know 
whether the next hop wants you to pop the stack or not, segment routing 
needs to have a default, and the only sensible default is "don't do 
PHP".  This should be stated in whatever document discusses the use of 
the MPLS data plane for segment routing.  I don't see that there is any 
issue for the MPLS WG.

> If A does not want PHP then it would have to advertise the prefix SID 
> so it could specify desired behavior using P/E flags.
>

A default of "do PHP" doesn't seem sensible, as it may result in the 
exposure of a label at a node that cannot process it properly.

> Historically,  MPLS implementations have chosen a default behavior 
> (equivalent to P and E flags = 0). Some implementations provide knobs 
> to override this behavior.
>

I wonder if you're thinking about the case where the next hop has 
advertised Implicit NULL for a particular FEC, but the current hop 
actually uses Explicit NULL in order to have a place to put the TC 
field, which would otherwise be lost when PHP is done.  That doesn't 
really seem relevant to the issue that Shraddha raised.
>
> If your concern is that there is not an explicit definition of default 
> PHP/Explicit NULL behavior, then I think this needs to be directed at 
> the MPLS WG.
>

I think this is incorrect, as explained above.

> I do not claim to be an MPLS expert, but I have found these references:
>
> RFC 3036 Section 6
>
> “- Section 2.16 of the MPLS architecture [RFC3031] requires that
>
> negotiation.”

Well, you don't have to be an MPLS expert to notice that RFC3036 was 
obsoleted ten years ago ;-)

In any event, the above quote is not relevant.  It simply says that when 
using LDP, an LSR may assume, for most data link types, that an LDP peer 
is capable of popping the top label off the stack.  Thus it is allowable 
to advertise to the peer a binding of Implicit NULL to a FEC.  This is 
an issue for LDP, but there is no way to apply the quoted passage to 
segment routing.

This really needs to be addressed in some SPRING draft or other.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 11 May 2017 11:30:08 +0000

Hi all,
I concur with Eric that the only reasonable default for SR over MPLS (and for MPLS in general) should be "No PHP".
Specifically, from my POV, if a SR-capable node with SGB base <B> and Node SID <S> receives a labeled packet with top label <B+S>, this label MUST be terminated regardless of whether the node did or did not advertise PHP.

I wonder whether this has ever been explicitly specified in one of the SR documents.

Do I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: spring [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Wednesday, May 10, 2017 5:27 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] Mail regarding draft-ietf-spring-conflict-resolution

I'm not sure why you think there is such a thing as "default MPLS behavior" in this regard.  In conventional MPLS, when a node advertises the binding of a label to a FEC, PHP will not occur unless the advertised label is Implicit NULL.   If you advertise a different label, you don't get PHP.

If there were any such thing as a default behavior for MPLS, it wouldn't make any sense for PHP to be the default behavior.   You can only advertise Implicit NULL if you know that the packet can be properly processed after the top label is popped off.  Whether PHP will give the right result is application-specific.  So if there were a default behavior, it would have to be "don't do PHP".  But of course MPLS has no need of such a default behavior, because each node advertises its own labels.

Since the segment routing architecture allows cases where you don't know whether the next hop wants you to pop the stack or not, segment routing needs to have a default, and the only sensible default is "don't do PHP".  This should be stated in whatever document discusses the use of the MPLS data plane for segment routing.  I don't see that there is any issue for the MPLS WG.

A default of "do PHP" doesn't seem sensible, as it may result in the exposure of a label at a node that cannot process it properly.

I wonder if you're thinking about the case where the next hop has advertised Implicit NULL for a particular FEC, but the current hop actually uses Explicit NULL in order to have a place to put the TC field, which would otherwise be lost when PHP is done.  That doesn't really seem relevant to the issue that Shraddha raised.

If your concern is that there is not an explicit definition of default PHP/Explicit NULL behavior, then I think this needs to be directed at the MPLS WG.

RFC 3036 Section 6

Well, you don't have to be an MPLS expert to notice that RFC3036 was obsoleted ten years ago ;-)

In any event, the above quote is not relevant.  It simply says that when using LDP, an LSR may assume, for most data link types, that an LDP peer is capable of popping the top label off the stack.  Thus it is allowable to advertise to the peer a binding of Implicit NULL to a FEC.  This is an issue for LDP, but there is no way to apply the quoted passage to segment routing.

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 12 May 2017 09:51:24 -0400

On 5/11/2017 7:30 AM, Alexander Vainshtein wrote:
> Specifically, from my POV, if a SR-capable node with SGB base <B> and 
> Node SID <S> receives a labeled packet with top label <B+S>, this 
> label MUST be terminated */regardless of whether the node did or did 
> not advertise PHP/*.

This seems like it might be too strong a requirement.  If the node is 
expecting PHP, I don't think it is reasonable to expect it to set up its 
data plane forwarding structures to handle both the PHP and the non-PHP 
case.

We might also question the statement that Les made: "[if] there is no 
advertisement of P/E for any of the destinations. It must follow a 
default behavior [when deciding whether to use PHP]".

Proper operation of the system seems to require that everyone knows when 
to do PHP and when not to do it.  If all the progamming of the data 
plane is done by a controller, it has to program the nodes 
consistently.  If the programming of the data plane is done by a control 
plane, and control plane errors or config errors cause inconsistent 
programming of the data plane, it would be nice if there were some way 
of detecting this and perhaps taking some deterministic remedial 
action.  While the scenario under discussion is not, strictly speaking, 
a "SID conflict", it does have a strong resemblance to the SID conflict 
case, in that the control plane is advertising an inconsistency that is 
likely to break things.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 12 May 2017 23:55:56 +0000

Eric -

First I want to say that this input is exactly what I was hoping to get.
Thanx.

We also had concluded that the issue of default PHP behavior is applicable to SR-MPLS precisely because  advertisements are globally scoped.  As it is possible in some circumstances (SRMS advertisement on behalf of an SR capable node is the most practical example) that explicit indication of the desired PHP behavior is not advertised a default behavior is required.

We are assuming a default behavior of PHP for SR-MPLS. If folks believe this requires explicit specification I would propose language similar to the following:

"When Segment Routing is instantiated over the MPLS data plane the penultimate node performs the NEXT operation (i.e., MPLS pop) unless a specific indication to do otherwise is advertised by the ultimate node."

As to why we are choosing PHP rather than UHP as the default, it is our belief that most of the platforms which support MPLS today have been implemented to take advantage of the optimizations that PHP affords. In some cases it may even be true that UHP is not supported at all. Of course if UHP is required prefix-SID advertisements provide the means to indicate this.

I hope this resolves the issue.

(NOTE: I will discuss the issue of anycast advertisements w/wo a SID in a separate email)

   Les

From: Eric C Rosen [mailto:[email-masked]]
Sent: Wednesday, May 10, 2017 7:27 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] Mail regarding draft-ietf-spring-conflict-resolution

RFC 3036 Section 6

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 16 May 2017 09:43:57 -0400

On 5/12/2017 7:55 PM, Les Ginsberg (ginsberg) wrote:
>
> We are assuming a default behavior of PHP for SR-MPLS. If folks 
> believe this requires explicit specification I would propose language 
> similar to the following:
>
> /"When Segment Routing is instantiated over the MPLS data plane the 
> penultimate node performs the NEXT operation (i.e., MPLS pop) unless a 
> specific indication to do otherwise is advertised by the ultimate node."/
>
>
I think this certainly needs to be stated explicitly, perhaps in the 
document that specfies the use of the MPLS dataplane for SR.

It should also be noted that there are circumstances under which the 
default will not produce the required behavior, so it may not always be 
safe to use the default behavior.  (For example, if a SID represents a 
multicast tree, and the payload is an MPLS packet that begins with an 
upstream-assigned label, PHP just won't produce the proper result 
because the label that was popped provides the context for interpreting 
the upstream-assigned label that has now risen to the top of the stack.)

> As to why we are choosing PHP rather than UHP as the default, it is 
> our belief that most of the platforms which support MPLS today have 
> been implemented to take advantage of the optimizations that PHP 
> affords. In some cases it may even be true that UHP is not supported 
> at all.
>

I believe you are correct about this.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 14:04:58 +0000

Hi all,
I concur with Eric, and I would like to mention yet another (albeit similar) use case where PHP MUST NOT be used with SR LSPs.

RFC 8104<https://tools.ietf.org/html/rfc8104> describes the PW egress endpoint protection mechanism that uses bypass tunnels between the PLR and the "Protector" node.
The top label of the bypass tunnel is used by the Protector node as the "context label" for the next (PW) label in the label stack, and hence PHP MUST NOT ever be used with these tunnels.

RFC 8104 claims that it is applicable to any technology that sets up tunnel LSPs (it explicitly states that it is applicable to LDP LSPs), so I assume that  it should be able to operate with SR LSPs as well.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Tuesday, May 16, 2017 4:44 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] Mail regarding draft-ietf-spring-conflict-resolution

I think this certainly needs to be stated explicitly, perhaps in the document that specfies the use of the MPLS dataplane for SR.

It should also be noted that there are circumstances under which the default will not produce the required behavior, so it may not always be safe to use the default behavior.  (For example, if a SID represents a multicast tree, and the payload is an MPLS packet that begins with an upstream-assigned label, PHP just won't produce the proper result because the label that was popped provides the context for interpreting the upstream-assigned label that has now risen to the top of the stack.)

As to why we are choosing PHP rather than UHP as the default, it is our belief that most of the platforms which support MPLS today have been implemented to take advantage of the optimizations that PHP affords. In some cases it may even be true that UHP is not supported at all.

---

From: <[email-masked]>
Date: Tue, 16 May 2017 14:32:27 +0000

> -----Original Message-----
 > Sent: Friday, May 12, 2017 3:51 PM
 > To: Alexander Vainshtein; Les Ginsberg (ginsberg); Shraddha Hegde; draft-ietf-spring-
 > [email-masked]
 > Cc: [email-masked]
 > Specifically, from my POV, if a SR-capable node with SGB base <B> and Node SID <S>
 > receives a labeled packet with top label <B+S>, this label MUST be terminated regardless of
 > whether the node did or did not advertise PHP.
 > 
 > This seems like it might be too strong a requirement.  If the node is expecting PHP, I don't
 > think it is reasonable to expect it to set up its data plane forwarding structures to handle
 > both the PHP and the non-PHP case.
 > 
 > We might also question the statement that Les made: "[if] there is no advertisement of P/E
 > for any of the destinations. It must follow a default behavior [when deciding whether to use
 > PHP]".
 > 
 > Proper operation of the system seems to require that everyone knows when to do PHP and
 > when not to do it.  If all the progamming of the data plane is done by a controller, it has to
 > program the nodes consistently.  If the programming of the data plane is done by a control
 > plane, and control plane errors or config errors cause inconsistent programming of the data
 > plane, it would be nice if there were some way of detecting this and perhaps taking some
 > deterministic remedial action.  While the scenario under discussion is not, strictly speaking,
 > a "SID conflict", it does have a strong resemblance to the SID conflict case, in that the
 > control plane is advertising an inconsistency that is likely to break things.

Eric,

thank you for your useful feedback.

I see 3 cases:

1) When a node advertise its own SID,

It looks to me that the architecture document is clear about the behavior:

"A Node N
      advertising a Prefix-SID SID-R for its attached prefix R unsets
      the P-Flag (or NP-Flag) in order to instruct its connected
      neighbors to perform the NEXT operation while processing SID-R.
      This behavior is equivalent to Penultimate Hop Popping in MPLS.
      When the flag is unset, the neighbors of N MUST perform the NEXT
      operation while processing SID-R.  When the flag is set, the
      neighbors of N MUST perform the CONTINUE operation while
      processing SID-R."

https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.1.2

2) For the case where the SID is advertised by a Mapping Server, 

it looks to me that the normative behavior is defined in https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-12#section-2.4.5.2

Eric, it would be useful if you could review this text and provides comments.
On my side, I feel that the text could be reworked to normatively specify when PHP MUST be done (aka SR NEXT) and when UHP (aka SR CONTINUE) MUST be done  (and explicit null MUST NOT be used)

3) For the anycast case raised by Shraddha,

One option may be to handle this case in draft-ietf-spring-mpls-anycast-segments. https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-01

Especially since it states "Like unicast prefix segments, anycast prefix segments SHOULD be advertised in IGP Link-state advertsements using IGP protocol extension for SR specified in  [I-D.ietf-isis-segment-routing-extensions],  [I-D.ietf-ospf-segment-routing-extensions]" 
which seems to exactly brings Shraddha's question. (i.e. what is the behavior if they are not)

Thanks,
--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.