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

[Dieter Beller <[e-mail]>]

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/" rel="nofollow">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] 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" rel="nofollow">​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.

-----

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

-----

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

-----

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

-----

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

----

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

----

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

----

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

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.

---

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.

---

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

---

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

---

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

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.

---

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

---

"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. Shall this assumption be explicitly stated?

---

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

----

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

--- 

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.

 

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]

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.