Re: [RTG-DIR] Rtgdir Last Call Review of draft-ietf-teas-lsp-diversity-07

[<[e-mail]>]

Hi Dieter, co-authors,

Thanks for your feedback.
Please see inline [Bruno]

From: rtg-dir [mailto:[e-mail]] On Behalf Of Dieter Beller
Sent: Sunday, July 02, 2017 11:57 AM
To: DECRAENE Bruno IMT/OLN; [e-mail]
Cc: [e-mail]; [e-mail]; BRUNGARD, DEBORAH A (ATTSI); [e-mail]
Subject: Re: [RTG-DIR] Rtgdir Last Call Review of draft-ietf-teas-lsp-diversity-07

Hi Buno, all,

please find our response to your comments inline below.

We have just submitted the 08-version of the draft - see: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/

Please don't hesitate to further discuss with us your review comments that did not yet result in document changes.


Thanks,
Dieter and co-authors

On 23.05.2017 17:18, [e-mail]<mailto:[e-mail]> wrote:

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-teas-lsp-diversity-07
Reviewer: Bruno Decraene
Review Date: 2017/05/23
IETF LC End Date: not initiated AFAIK
Intended Status: Standard Track
Summary:
I have some minor concerns about this document that I think should be resolved before publication.
Comments:
I have only very basic knowledge of RSVP-TE and none of GMPLS. I found the document very clear. Thank you.
Major Issues:  None
Minor Issues:
To provide diversity, my understanding is that the signaling of the second LSP is extended to detect the crossing of the first path, and then is re-routed to avoid it. In some cases, I guess that providing path diversity is not possible without re-routing the first path. It's not clear to me how this is possible with this proposition.

You comment is indeed a valid. Our assumption, however,  was that the two LSPs are requested sequentially and there can be a longer period of time
between the UNI request for the first LSP and the UNI request for the second LSP (days, weeks, months). This draft provides a UNI signaling solution
that allows an Edge Node (EN) to signal a diversity constraint to the ingress Core Node (CN) when it requests the 2nd LSP such that path computation
can take this diversity constraint into account. Re-routing the first LSP that may already exist for a longer period of time was not considered.


Depending on the technology of the core network, re-routing the first LSP may not be desired because it may not be possible  without a traffic
disruption (e.g. in WDM transport networks).


If it’s not, this limitation should probably be highlighted somewhere in the document. (and if it is, sorry for having missed it). Especially since this case seem to be in scope as per the Introduction: "Similarly, an LSP from EN2 to EN3 traversing CN1 needs to be diverse from an LSP from EN2 to EN3 going via CN4. [...]  This document addresses these diversity requirements "

We deliberately did not take any assumption whether the a PCE is used or whether path computation is done in a distributed way. If distributed path
computation was used coordination between the path computation functions would be be required, which is an assumption that may not be true. Therefore, we also assumed that the 2 LSPs are signaled sequentially, one after the other.

See updated abstract.
[Bruno] ok. I’d propose the following change
OLD:

   The solution described in this document is based on the assumption
   that LSPs are requested sequentially, i.e., the time period between
   the LSP setup requests for the two LSPs may be longer (days, weeks,
   months). Re-routing the first LSP that may have existed for a longer
   period of time is not considered.

NEW:
   The solution described in this document is based on the assumption
   that LSPs are requested sequentially. The solution allows the new LSP to be diverse from the previously setup LSP(s). Re-routing the previous LSPs
is not considered which may result in the inability to found a diverse path for the new LSP.


-----
§1.1
"There are scenarios in which the ENs have the following requirements"
OK. Are there other scenario? (seem so as per the wording). What are their requirements and why aren’t they considered?

Requirements in section 1.1 removed - was helpul fwhile the solutions were developed.
[Bruno] ok

-----
"-  Both client and server understand the identifier."
Not sure what is meant by "understand". At this step, it's not clear why the identifier can't be an any number/string that no one understand but is treated as an opaque value/identifier.

Requirements in section 1.1 removed - was helpul while the solutions were developed.

[Bruno] ok
-----
"The identifier is to be stable for a long period of time."
Easy comment but "long" is not very specific and different person may have different interpretation. I guess that the goal is that the identifier be stable for the duration of the diversity requirement.

Requirements in section 1.1 removed - was helpul while the solutions were developed.

[Bruno] ok
-----
" These requirements are met by using the LSP identifier. The LSP
      identifier uniquely identifies an LSP in the network and
      comprises of the following fields: IPv4/IPv6 tunnel sender
      address, IPv4/IPv6 tunnel end point address, Tunnel ID, LSP ID,
      and Extended Tunnel ID. These fields are defined in [RFC3209],
      sections 4.6.1.1 and 4.6.2.1."
It's not clear to me that this choice meet the requirements. As per my quick reading of RFC 3209, Tunnel ID remains constant for the lifetime of a tunnel. If the node (e.g. EN1) reboot, it seems plausible that this Tunnel ID be changed. That seems to be an issue given that this identifier seems to be statically configured on the other node (e.g. EN2)

According to our understanding, the Tunnel ID remains unchanged for the lifetime of an LSP. All implementations, the authors are aware of, store the
Tunnel ID in a persistent data base. This guarantees that the Tunnel ID does not change after a node restart.

[Bruno] If you need non-standardized function, may be this would need to be stated in the document.
In addition, although I have very limited knowledge of RSVP-TE, https://tools.ietf.org/html/rfc3209#section-2.5 seems to state that during LSP rerouting, the LSP ID is changed.

----
"In order to
      maintain diversity between these two connections within the core
      network, it is assumed that the core network implements Crankback
      Signaling [RFC4920]."
Don't you mean :s/assume/REQUIRED  ?

Changed as suggested.

[Bruno] ok
----
§1.2 PCE-allocated Identifier
If PCE is used to compute the paths, paths diversity needs to be handled by the PCE (to compute diverse paths). In which case, the problem seems to be solved with no need for further RSVP-TE extensions.
Figure 2 seem to illustrate that this section seem to consider the case where PCE is only partially used (in one domain). This is not stated at the beginning of 1.2 hence this does not help the reader to understand the case really being considered.

Maybe Figure 2 is a bit misleading as it shows a different scenario (multi-domain) compared to Figure 1. Using Figure 1 as reference, the assumption is
again that the EN uses RSVP signaling to setup two LSPs that shall follow divers paths in the core network. This means that two different core nodes,
let' say CN1 and CN4 will receive the PATH messages for two LSP and it will be the centralized PCE that has to deal with the diversity constraint. In the
PCE case, the existing Path Key subobject is (re-)used to allow a client network EN to request a 2nd LSP with the Path Key subobject included that
indicates towards the PCE that the path for the 2nd shall be divers w.r.t. the LSP associated with the Path Key.

Would you suggest to change Figure 2 and align it with Figure 1? However, this would also require to align the text with the new figure.

[Bruno] I may have lost context. But I guess my point what that this lsp-diversity extension is required because multi domain is used. Now using figure 1 as reference, EN initiating the RSVP-TE session and CN calling the centralized PCE are in a different domain. (not sure “domain” is the right technical term). If a single domain is used, with the node initiating the RSVP-TE session being the same as the node initiating the PCE session (e.g. one LSP from nodes CN1 to CN3, another LSP from CN4 to CN5 with diversity requirement), then there don’t seem to be a need for RSVP-TE extension, as only the PCE / PCEP need to understand this diversity constraint.
Forget about this, the addition context that you introduced in the Abstract is now clear enough, although I’m not sure that the following sentence parses very well:

Three different
   mechanisms are supported how LSP diversity can be accomplished in
   the provider or core network: the signaled diversity type, indicates
   whether diversity is based on client, path computation engine (PCE),
   or network assigned identifiers.

I’d propose the following text, but any other reformulation is fine:
Three different mechanisms are defined to provide LSP diversity in the provider or core network. The signaled Diversity Identifier type indicates whether diversity is based on client, path computation engine (PCE),
   or network assigned identifiers.
----
§1.3
"the concept of a Path Affinity Set (PAS) is defined for abstracting SRLG information."
It's not clear to me how the second node (EN2 using the example from the introduction) is communicated this PAS from EN1, and how it's kept up to date as the path used by EN1 may change.
IOW, this PAS does not seem to fulfill the 3 latest requirements listed in 1.1:
"       -  It is necessary to be able to reference the identifier even if the LSP referenced by it is not yet signaled.
        -  The identifier is to be stable for a long period of time.
        -  The identifier is to be stable even when the referenced LSP is rerouted."

It's not clear to me what benefits this PAS brings compared to the client initiated identifier. While it adds the above disadvantages.

The draft addresses 3 use cases, where for the use cases 2 and 3 the network assigns the identifiers that are used to achieve diversity between LSPs:

  1.  The client assigns a unique diversity identifier to the LSP.
  2.  In case a PCE is used (centralized patch computation), the PCE assigns a Path Key to the LSPs
  3.  In case of distributed routing and path computation, the path computation function assigns a PAS to the LSPs. The assigned PASes and the
related path computation constraints (e.g. list of SRLGs) have to disseminated in the network such that all path computation instances have
that information and can calculate a path for a new LSP that meets the requested diversity constraints.

So, the PAS approach is needed to ahave a complete solution for the problem addressed in this draft.
[Bruno] thanks for clarifying the 3 use cases. My question was whether the third use case could also have been addressed using a "Client Initiated Identifier" instead of defining a new Diversity Identifier Type. Indeed, a priori, even in the use case 3, you have the knowledge of a (tunnel end point address, Tunnel ID, Extended ID, LSP ID), which could be used to uniquely identify the LSP, no?
But it’s not a big deal. This is more for my information.


Please let us know if you have further comments or suggestions how the document can be improved.


---
"The means by which the processing node determines the path corresponding to the PAS is beyond the scope of this document."
But this doesn't remove the problem to be solved. You seem to assume that there is one single database, typically centralized. An alternative option may have been to cypher the "detailled SRLG list". Why has this option been discarded?

The PAS-based solution has been defined when distributed routing and path computation is used in the core network. This means that the PAS
information is preferably disseminated into the network by the IGP (e.g. OSPF-TE) such that all nodes have the information. An alternative solution
could be that the PAS information is managed by a centralized entity. Encrypting SRLG information was not considered. RFC8001 can be used to
exchange SRLG information in an non-encrypted form.


"The means to distribute the PAS information within the core network is beyond the scope of this document. For example, the
      PAS and the associated SRLG information can be distributed within the core network by an Interior Gateway Protocol (IGP) or by other means such as configuration."
I don't think the use of the IGP would be such a good fit, in term of frequency of update (ok, this is deployment dependent) and scalability (a priori the number of PAS is o(N^2), N being Core Nodes.)

The number of PAS instances depends on the number of LSPs in the network that shall meet diversity constraints signaled by the client network that
does not know the topology of the core network (UNI).

If LSPs are for example protected inside the core network, diversity can be achieved without a PAS.

[Bruno] ok.
---
Abstract: " This document specifies three new route exclusion types."
From the IANA section and the document ToC, I'm seen only 2 types: "IPv4 Diversity subobject", "IPv6 Diversity subobject"

see comments above. The document defines 3 DI types and 2 new diversity subobjects (IPv4 and IPv6) containing the DI type field.

[Bruno] ok as the abstract have been updated.
---
"IANA section"
You do not define a registry nor a registration policy for the "DI Type"

We did the IANA section based on the guidance provided by Lou (TEAS co-chair) and I thought what we did was fine as Lou did not provide
any comment when he reviewed the document. The document describes precisely which IANA registries shall be extended to support the
diversity subobjects and error codes defined in the document.

[Bruno] That’s not exactly an answer to my question, but I guess that your answer is that you don’t think there is need for a registry for this “DI Type”. e.g. you don’t foresee (much) extensions. That would work for me.
---
§2.1
The A-Flags field is 4 bits longs and this document already allocates 4 flags, meaning that there is no room for extension (although there is a 4 bits Reserved field available)

As you mention, there is a reserved field that has 4 bits.

[Bruno] ok
---
§2.1
If A-Flags "0x01 = Destination node exception" and "0x04 = Penultimate node exception" are both set, it seems that the penultimate link (between these 2 nodes) should also be excluded from the exclusion list. If so this should be specified.

There can be multiple links between the Destination node and the Penultimate node. If none of these links meets the required diversity constraint,
it is better to reject the LSP setup.

[Bruno] ok

NOTE: the Destination node and the Penultimate node are topological exceptions.


---
"When the diversity identifier type is set to "IPv4/ IPv6
              Network Assigned Identifier", the value MUST be set to the
              IPv4/ IPv6 address of the node publishing the Path
              Affinity Set (PAS)."
Given that the way the PAS is advertised (I read 'publish') is out of scope of this document, I'd rather not use the term "publishing". I guess "allocating" would be better and probably more accurate.

Changed as suggested.

[Bruno] ok
---
§3
"the diversity subobject must be kept while other subobjects may be removed."
Do you mean :s/must/MUST  ? (it looks to me that this is required for interop, hence a MUST)

Changed as suggested.

[Bruno] ok
---
"all Diversity subobjects in an XRO/ EXRS MUST contain the same Diversity Identifier Type."
Could you clarify the reason?
What if someone wants to be diverse with 2 others LSP: one intra-domain using a client-Initiated Identifier, and another one inter-domain using a "PCE-allocated Identifier"?

This statement is based on the assumption that only one diversity type is used in the core network even if the core network is composed of
multiple core network domains.
[Bruno] ok

Shall this assumption be explicitly stated?
[Bruno] No. I assume that you have a reason for this assumption. But why do you need to put it as a MUST in the protocol specification? IOW, it’s fine if a given implementation has this assumption and does not support multiple DI types. But I’m not sure why you want to forbid it with a MUST as I’m not seen interop issues. (well, no more than a client only supporting DI Type 1 while the core only support DI Type 3).


---
§2.3
"it MUST return a PathErr with the error code TBA3 "Routing Problem" and error value of "Unsupported Diversity Identifier Type"
I think I would propose
"code "Routing Problem" (24) and error value of "Unsupported Diversity Identifier Type (TBA3)"

Changed as suggested.
[Bruno] ok


----
§2.3
"The transit nodes in a domain and the domain egress node SHOULD NOT process the signaled diversity information."
This does not seem to match " In order to
      maintain diversity between these two connections within the core
      network, it is assumed that the core network implements Crankback
      Signaling [RFC4920]."
As I understand, by the latter, that all RSVP-TE nodes need to process the diversity information. But this may comes from my lack of knowledge of RSVP-TE.

See updates in section 2.3.

[Bruno] ok

---
Nits:
Impressive list of contributors: 1,5 pages, 16 persons (in additions to 4 authors)

The reason for the long list is that we merged 3 drafts into a single draft as requested by the CCAMP chairs when 3 separate drafts existed.
[Bruno] ok
Best regards,
--Bruno

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.

--

Dieter Beller
Open Agent & Routing Project Manager
IP/Optical Networks, Optics, Nokia

t: [phone] | m : [phone] | OnNet: 259 43125
[e-mail]<mailto:[e-mail]>
Alcatel-Lucent Deutschland AG | Lorenzstr. 10 | 70435 Stuttgart
Sitz der Gesellschaft | Domicile of the Company: Stuttgart · Amtsgericht Stuttgart HRB 4026
Vorsitzender des Aufsichtsrates | Chairman of the Supervisory Board: Prof. J. Menno Harms
Vorstand | Board of Management: Wilhelm Dresselhaus (Vorsitzender | Chairman) · Ralf Niederberger

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.

_________________________________________________________________________________________________________________________

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.