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

From: <[email-masked]>
Date: Thu, 12 May 2016 15:22:36 +0000

Hi,

As an individual contributor, please find below some comments:

--
Isn't this document specific to the MPLS dataplane?
If so, it could be indicated in the introduction, and possibly in the abstract. Then this indication could be removed from the 1rst sentence of sections 2 & 3.
--
§3
"Mapping entries have an explicit context which includes the topology and the SR algorithm."
A priori you could add "the routing protocol".
--
§3

"When conflicts occur, it is not

   possible for routers to know which of the conflicting advertisements

   is "correct".  If a router chooses to use one of the conflicting

   entries forwarding loops and/or blackholes may result unless it can

   be guaranteed that all other routers in the network make the same

   choice.  Making the same choice requires that all routers have

   identical sets of advertisements and that they all use the same

   selection algorithm. »

I think we agree on the technical part, but I found the formulation slightly biased. I would propose

"When conflicts occur, it is not

   possible for routers to know which of the conflicting advertisements

   is "correct".  In order to avoid forwarding loops and/or blackholes, there is a need for all nodes to make the same choice.

  Making the same choice requires that all routers have

   identical sets of advertisements and that they all use the same

   selection algorithm. This is the purpose of this document. »
--
§3.1

"Various types of conflicts may occur"

What about :s/Various/Two
--
I agree with Robert's  and Uma's comment with regards to making this conflict resolution an inter- protocol/routing_table issue. In particular, between SR domains, there is not requirement to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused independently).

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]] > Sent: Sunday, May 01, 2016 7:11 AM
>
> We are indeed defining conflict resolution across all the SID advertisements regardless of source (protocol or SRMS)
> Why? Because we need consistent use of SIDs in the forwarding plane

No: in the forwarding plane, we need a consistent use of MPLS label.
Plus only within an SR domain. Actually, even within a domain, this is dependent on whether SRGB is configured on a per node or a per protocol basis. I'm not sure how much the agreement has been reached on that one.

--
Typo:
§2
OLD : Range 3: (500, 5990
NEW : Range 3: (500, 599)

(somewhat significant as otherwise range 3 conflict with range 2)

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 14 May 2016 18:29:31 +0000

Bruno -

Inline.

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 12, 2016 8:23 AM
To: [email-masked]
Subject: [spring] draft-ietf-spring-conflict-resolution

Hi,

[Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open the possibility that if there is some SRv6 conflict resolution that needs to be specified it could be added into this document - which is why the Introduction is dataplane agnostic, but each section states specifically that it is relevant to SR-MPLS.

I am not aware of any SRv6 conflict resolution that is required at this point, but I prefer to leave the possibility open if that is OK with you.

[Les:] No - the source of advertisements is deliberately left out. It matters not whether the source of the advertisement is a protocol or an SRMS - nor does it matter which protocol provides the advertisement. You see that "admin distance" is not mentioned at all and that is quite deliberate. This insures that consistent choices are made on nodes regardless of which protocol might have the best route on a given node.

--
§3

   selection algorithm. »

   selection algorithm. This is the purpose of this document. »
--
[Les:] I am fine with this change.

§3.1

[Les:] "Two" is fine. Just means we will have to change it if we come up with a third type of conflict. :)
--
I agree with Robert's  and Uma's comment with regards to making this conflict resolution an inter- protocol/routing_table issue. In particular, between SR domains, there is not requirement to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused independently).

[Les:] There is more to be said on this topic - co-authors are actively discussing this point and we'll respond more fully to Robert's post in time. But, the draft is NOT trying to define conflict resolution across "SR domains". Perhaps we need language to make that more explicit.

No: in the forwarding plane, we need a consistent use of MPLS label.
[Les:] As you know, SRGB range can be different for different nodes, so the actual label that is used to send a packet for a given destination via Node A may be different than the label used to send the same packet via Node B. It is the SID that needs to be the same - not the label.
It is true that SIDs are not installed in the forwarding plane - the labels derived from the SID/SRGB are what is actually installed in the forwarding plane - but I think my use of the word SID in this context is correct.

[Les:] The draft currently addresses deployments where a single (set of) SRGB ranges applies to the box. This is by far the most common use case. There is a much more limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address that in a future revision - but in spirit the same rules will apply - they will just have to take into account "duplicate forwarding domains". Note that this will also require multiple incoming label entries/prefix be supported by the routers in such a network.

[Les:] Agreed - thanx for spotting this.

   Les

Thanks,
Regards,
Bruno

Thank you.

---

From: <[email-masked]>
Date: Wed, 18 May 2016 11:56:55 +0000

Les,

Thanks for your reply.
Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution

Bruno -

Inline.

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, May 12, 2016 8:23 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] draft-ietf-spring-conflict-resolution

Hi,

[Bruno] ok, great.

[Les:] No - the source of advertisements is deliberately left out. It matters not whether the source of the advertisement is a protocol or an SRMS - nor does it matter which protocol provides the advertisement. You see that "admin distance" is not mentioned at all and that is quite deliberate. This insures that consistent choices are made on nodes regardless of which protocol might have the best route on a given node.
[Bruno] Well, the fact is that mapping entries do have, as explicit context, the routing protocol used to advertise them. After, you can should to use that information, or not.
--
§3

   selection algorithm. »

[Bruno] Thanks

§3.1

[Les:] "Two" is fine. Just means we will have to change it if we come up with a third type of conflict. :)
[Bruno] Indeed, but in this case the change may be much larger (e.g. the whole algo)
--
I agree with Robert's  and Uma's comment with regards to making this conflict resolution an inter- protocol/routing_table issue. In particular, between SR domains, there is not requirement to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused independently).

[Les:] There is more to be said on this topic - co-authors are actively discussing this point and we'll respond more fully to Robert's post in time. But, the draft is NOT trying to define conflict resolution across "SR domains". Perhaps we need language to make that more explicit.
[Bruno] ok. Regarding inter-protocol, in order to have consistency of the prefix-SID mapping across the domain we need:
a) all nodes use the same algo
b) all nodes using this algo have the same data

"a" requires this draft
"b" requires that all nodes have the same set of SR  info. This forbid that some node are considering IS-IS + OSPF SR data, while some node are only considering IS-IS data. Otherwise, all IS-IS routers would not take the same decision. So, unless we can guarantee that the flooding area is the same for IS-IS and OSPF, we can't have the algo using the SR data from multiple routing protocols. I don't think that we can guarantee this (nor that implementation will check this) e.g. when some nodes are part of multiple routing domain or when gradually transitioning from one IGP to another.

So in short, this SR-conflict algo should probably be restricted to SR information from a single protocol

No: in the forwarding plane, we need a consistent use of MPLS label.
[Les:] As you know, SRGB range can be different for different nodes, so the actual label that is used to send a packet for a given destination via Node A may be different than the label used to send the same packet via Node B. It is the SID that needs to be the same - not the label.
It is true that SIDs are not installed in the forwarding plane - the labels derived from the SID/SRGB are what is actually installed in the forwarding plane - but I think my use of the word SID in this context is correct.
[Bruno] My point was that the formulation assumes that a single SRGB is used per nodes. In which case, we have a bijection between SID and labels. But if we have a SRGB per protocol, we don't have a bijection any more and we can have the same SID in IS-IS and OSPF (including for different prefix), which will be mapped to different labels in the forwarding plane.

[Les:] The draft currently addresses deployments where a single (set of) SRGB ranges applies to the box. This is by far the most common use case. There is a much more limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address that in a future revision
[Bruno] ok, may be this should be stated in the draft, as otherwise you'll keep getting comments, or we may forget this point.
Thanks
--Bruno
- but in spirit the same rules will apply - they will just have to take into account "duplicate forwarding domains". Note that this will also require multiple incoming label entries/prefix be supported by the routers in such a network.

   Les

Thanks,
Regards,
Bruno

Thank you.