Hi Huaimo, et. al,
apologies for such very late response. I've read the -02 version and below
you'll find my notes to changes I've found. My responses to our discussion are
in-line and tagged GIM>>.
Notes to -02 version:
* section 5.1 states
A backup egress SHOULD be configured on the ingress of an LSP to
protect a primary egress of the LSP.
Are there scenario when this SHOULD NOT be done, when the backup egress(es) are
not configured?
And if this is such strong requirement, then the same is applicable to the next
sentence that currently reads as "...optional egress backup descriptor list for
protecting egresses of the LSP". I think that the descriptor list SHOULD be
included in the Path message by the ingress.
* section 5.2 states:
If the transit node is the upstream node of a primary egress to be
protected, it determines the backup egress, obtains a path for the
backup LSP and sets up the backup LSP along the path.
Which, in my view, contradicts with the statement in section 5.1 that backup
egress(es) SHOULD be configured at LSP ingress.
Regards,
Greg
From: Huaimo Chen [mailto:[email protected]]
Sent: Monday, April 13, 2015 8:19 PM
To: Gregory Mirsky; [email protected];
[email protected]; [email protected]
Cc: [email protected]; [email protected]
Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection
Hi Greg,
Thanks for your comments.
My answers/explanations are inline below.
Best Regards,
Huaimo
From: mpls [mailto:[email protected]] On Behalf Of Gregory Mirsky
Sent: Monday, April 13, 2015 2:58 PM
To:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection
Dear Editors,
please kindly consider my comments to the current version of this work:
* Introduction
o The third paragraph mentions that an end-to-end protection may be slower to
detect failure and perform switchover then an arbitrary local protection
method. I believe that that is not the case and, as been demonstrated by
deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec
switchover and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec.
[Huaimo] It seems that the statement in the paragraph is true. For a global
protection (or an end-to-end protection), it may take more time since the time
includes the propagation time and processing time. The propagation time may
depend on the size of the network. In general, the bigger the network, the
longer the propagation delay. The processing time may comprise the related
processing time on every node along the path from the egress node to a node
interesting the failure and doing switchover.
GIM>> I think that distance, whether in number of intermediate hops or miles,
does not affect guaranteed defect detection time when continuity check protocol
being used. In that case detection time depends only on definition of Loss of
Continuity defect for the given protocol. For example, in CFM it is period of
time between 3.25 and 3.5 CCM intervals when no CCM received from remote MEP.
BFD is little different and DetectMultiplier can be negotiated between end
points of the given BFD session. But regardless of these differences, using CFM
or BFD enables detection of LoC defect within 10 ms regardless of the distance
between end-points.
o The last in Section 1.1 suggests that node R3 may detect failure of the
node L1 through monitoring BFD session between two nodes. Firstly, if this is
multi-hop BFD session over IP network, then there's no guarantee that its path
is co-routed with the LSP segment R1-L3. Secondly, if it is assumed that RFC
5884 may be used, I have to remind, that RFC 5884 operates between LSP end
points and R1 is not end point. Thus, Sub-Path Maintenance Entity (SPME)
co-routed with the segment R1-L3 MUST be established.
[Huaimo] It seems that R3 is the upstream node of L1 and there is no multi-hop
BFD session between R3 and L1.
This current version of the document focuses on extending the protection of RFC
4090 from a transit node to an egress node. It seems that it is better to have
another document for others if needed.
GIM>> I couldn't find in the document statement that the PLR R3 MUST be
upstream to the egress. If this is the requirement, then it must be explicitly
stated as, in my view, it is restrictive and limits number of networks where
proposed method can be used.
* Section 5.2
o The third paragraph assumes that if a PLR cannot establish LSP to any
listed LSR in the EGRESS_BACKUP object it SHOULD select it locally and record
it in the EGRESS_BACKUP object. I believe that that implies that a PLR, i.e.
any LSR in the MPLS domain is aware of all services, i.e. CEs, as that is
required when selecting backup egress. That is serious security concern and
must be properly addressed in Security Considerations section of the draft.
[Huaimo] This paragraph says that the upstream node of the primary egress
knows/determines that there is not any backup egress given for the primary
egress. In this case, the upstream node selects a backup egress according to a
local policy. The upstream node may not need to be aware of any services or CEs.
GIM>> As commented above to section 5.2, this contradicts statement made in
section 5.1 that backup egress(es) SHOULD be configured at LSP ingress.
Regards,
Greg
