• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: bmwg

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

2013-03-14 11:16 (System)

RFC published

2013-03-14 07:43 (System)

RFC Editor state changed to AUTH48-DONE from AUTH48

2013-03-04 18:59 (System)

RFC Editor state changed to AUTH48 from RFC-EDITOR

2013-01-04 07:19 Amy Vezza

State changed to RFC Ed Queue from Approved-announcement sent

2013-01-03 11:04 (System)

IANA Action state changed to No IC

2013-01-03 10:54 Cindy Morgan

State changed to Approved-announcement sent from Approved-announcement to be sent

2013-01-03 10:54 Cindy Morgan

IESG has approved the document

2013-01-03 10:54 Cindy Morgan

Closed "Approve" ballot

2013-01-03 10:54 Cindy Morgan

Ballot approval text was generated

2013-01-03 10:53 Cindy Morgan

Ballot writeup was changed

2013-01-03 10:40 Ron Bonica

State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup

2012-12-14 11:05 Stewart Bryant

[Ballot comment]
I am updating my comment to clarify it. It is a point that was somewhat obliquely a Discuss last time round, but I did not properly explain the point. I would raise this as a discuss, but I do not think the review rules permit this.

The text that says : "MPLS FRR protection mechanisms are generally deployed in a network infrastructure where MPLS is used for provisioning of point-to-point traffic engineered tunnels (tunnel)." and the absence of discussion on the topic elsewhere suggests that you have not considered an important (arguably the most important) deployment case.

In an otherwise LDP network a one hop RSVP-TE tunnel is deployed across a link. This tunnel is normally PHPed, but is protected, so normally no label is pushed on the main tunnel. This case will impact the LSR configuration compared to the pure RSVP-TE case and will impact the restoration, because you have three routing process that interact - the IGP, LDP and RSVP-TE. You do the same think for node protection, but cannot of course PHP.

You might want to rule the case out of scope, although this will reduce the utility of the testing, or you could consider it, but you really ought to provide evidence that you have thought about the implications and validity of your tests in this network environment.

2012-12-14 11:05 Stewart Bryant

[Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss

2012-11-27 12:50 (System)

Sub state has been changed to AD Followup from Revised ID Needed

2012-11-27 12:50 Rajiv Papneja

New revision available

2012-11-15 11:26 Cindy Morgan

State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation

2012-11-15 10:03 Russ Housley

[Ballot comment]
Thanks for addressing the issues raised in the Gen-ART Review by
Joel Halpern on 9-Mar-2012. Joel did a second review on 12-Nov-2012.
Please consider these non-blocking comments from the second review.

In section 5.1 "some" failure events are listed. It is unclear
whether this list is the ones to be tested for, or just "some"
events. I think it is intended to be comprehensive, so why "some".

I presume that the use of the term Layer2 VC in section 6 is
intended to refer to a pt-to-pt layer2 VPN component. Is there an
existing document where that term is used that way? Could it be
referenced? For that matter, since the number of labels is the same
in the Layer3 cases and the Layer2 cases, could the Layer2 cases be
omitted without loss of generality?

2012-11-15 10:03 Russ Housley

[Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss

2012-11-15 07:28 Gonzalo Camarillo

[Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo

2012-11-15 07:26 Stewart Bryant

[Ballot discuss]
As far as I can see from reading the document the authors are considering FRR solely in the explicit case of MPLS-TE FRR being used to protect an MPLS-TE LSP. FRR and MPLS protection have developed considerably since that initial concept. Additionally one of the most common uses of MPLS-TE FRR is to protect a one hop tunnel with PHP (i.e. a null tunnel) which in turn is used as a method of protecting a hop in an LDP MPLS network.

Please can the authors make it much clearer in the introduction and scoping of the document that testing issues related to MPLS/LDP, IPFRR applied to MPLS networks (RFC5714 applied to MPLS), and MPLS-TP have not been taken into consideration, and are thus out of scope for this document.

I think that there is a zero label case that needs to be tested - one hop php tunnel at network egress protected by a TE tunnel.

Viewing the last 20 entries. Show full log.