Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 1 Mar 2014 18:26:29 +0000

I support the intent of this draft, and one of the detection mechanism described (3.3).

But I think the document is a bit miss leading the validity of detection/trigger part, which I hope will get discussed/updated further.

Some specific comments.

2.1, 3rd paragraph.

   Ra should be able to detect the failure of R1 and switch the traffic
   within 10s of ms.  The exact method by which Ra does so is out of
   scope.  Different options are discussed in this draft.

If the method to detect node failure of primary ingress is out of the scope, then how can the document claim protection switchover within 10s of milliseconds? Section 2.2 again mentions:

   The traffic switchover time is within tens of
   milliseconds whenever the ingress, any of the links and the
   intermediate nodes of the LSP fails.

It is a bit miss leading to state that protection can function within such small time window, because it is very dependent on how fast backup ingress can determine the node failure of primary ingress, which is outside the scope of this document.

2.1, last paragraph.

   Note that the backup egress must be one logical hop away from the
   ingress.  A logical hop is a direct link or a tunnel such as a GRE
   tunnel, over which RSVP-TE messages may be exchanged.

Did you really mean "backup egress"? Or should it be "backup ingress"?

3.1.

This option requires that the source and the backup ingress to synchronize the failure of the primary ingress. Otherwise the proposed will not work (ex: only the source detecting the failure will cause black hole). This should be spelled out.

3.2, first paragraph.

   Backup Detects Failure or Backup-Detect means that the backup ingress
   is responsible for detecting the failure of the primary ingress of an
   LSP.  The source SHOULD send the traffic simultaneously to both the
   primary ingress and backup ingress.

Why is it SHOULD and not MUST? If the source is not sending the traffic to backup ingress, then isn't it the same as 3.1 (Backup-Source-Detect)?

3.2, last paragraph.

This paragraph is implying that BFD can be used for backup ingress to detect "node failure" of primary ingress, but that is not true. This is miss leading, and limitations should be described or ... real detection mechanism should be described. And by limitation, you could easily get duplicated traffic.

-Nobo

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection-11
as an MPLS working group document. Since this call will continue through the
IETF meeting in London, I will extent the poll by one week (so that it will be a
three week poll).

Please send your comments (support/not support) to the mpls working group
mailing list ([email-masked]<mailto:[email-masked]>).

This poll will end Tuesday March 11, 2014. This is of course the Tuesday after
the IETF.

Thanks, Ross

---

From: Ross Callon <[email-masked]>
Date: Mon, 17 Mar 2014 01:23:35 +0000

Working Group,

This poll for adoption has been closed.  We have accepted the draft as an mpls working group document.

The change in name (replacing "p2mp" with "rsvp") that we have agreed to for draft-chen-mpls-p2mp-egress-protection logically should apply to this draft just as much as to the other draft, and the authors of this draft have agreed with the change.

Could the authors please re-publish the draft (draft-chen-mpls-p2mp-ingress-protection-11) with no other
changes than file-name, date and version as:

draft-ietf-mpls-rsvp-ingress-protection-00

After this draft has been posted, the authors should then deal with the comments received during the call for adoption, following normal IETF processes.

Thanks, Ross
(as WG co-chair)

Thanks, Ross