Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.txt

From: [email-masked]
Date: Tue, 03 Feb 2015 20:07:32 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF.

        Title           : Extensions to RSVP-TE for LSP Egress Local Protection
        Authors         : Huaimo Chen
                          Ning So
                          Autumn Liu
                          Tarek Saad
                          Fengman Xu
	Filename        : draft-ietf-teas-rsvp-egress-protection-01.txt
	Pages           : 17
	Date            : 2015-02-03

Abstract:
   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for locally protecting egress nodes of
   a Traffic Engineered (TE) Label Switched Path (LSP), which is a
   Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-egress-protection-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 4 Feb 2015 04:17:19 +0000

Hi Everyone,

    We updated the draft in this version (-01) according to Lou's comments. For your convenience, a brief explanation for the response to each of Lou's comments is inline below. We welcome your comments for the updated draft.

Best Regards,
Huaimo
> From: Lou Berger [mailto:[email-masked]]
> Sent: Wednesday, December 31, 2014 7:48 AM
> To: Huaimo Chen
> Cc: Ross Callon; [email-masked]; Lu Huang; Lei Liu; Lizhenbin; Autumn 
> Liu; Tarek Saad; Ning So; Fengman Xu; Mehmet Toy; Loa Andersson; 
> [email-masked]
> Subject: Re: Request for WGLC for 
> draft-ietf-teas-rsvp-egress-protection
>
> Huaimo,
>     I just took a quick skim through the document and see a few things that should be addressed:
>
> - You have a lot of names on the front page.  The RFC editor's guidance is a max of 5 names on the front page.  Getting to this number will smooth the publication  process.
> [Huaimo] Keep 5 names on the front page in the updated draft.
>
> - There are a number of nits that would be good to clean up.
> [Huaimo] Cleaned up.
>
> - You have conformance (RFC2119) language in informative text [Huaimo] 
> Removed conformance language in informative text.
>
> - You mention GMPLS, which is good, but don't mention how the document relates to RFC4872 and 4873.  I'm not saying that the document can't be limited to FRR protection, but do want to at least discuss if a unified approach can be found for FRR and 4873 style segment protection.  The conclusion of this discussion will need to reflected in someway in the document, either as a change in the mechanisms or an explicit statement of scope.
> [Huaimo] Removed GMPLS from abstract. But added some text relating to RFC 4873 in the document.
>
> - You can define values for objects/TLVs defined in this document.
> [Huaimo] Defined values for new objects/TLVs.
>
> - You combined v4/v6 object definition is subject to misinterpretation. 
> It needs to be clarified.  I suggest using past RFCs as a reference of how this can be done, e.g., see RFC4875.
> [Huaimo] Defined IPv4 and IPv6 objects separately.
>
> - You should reference where the FAST_REROUTE object is defined in 
> section 4.2 [Huaimo] Removed this section. Moved flags into EGRESS_BACKUP object since the flags are specific to egress protection.
>
> - Section 5 seems to be a mix informative and normative text.  It's not clear if all required behaviors have normative language. I suspect there are a number of cases missing - particularly, but not exclusively, in the language around processing that is the same as / different than RFC4090, which is generally very loosely defined.
> [Huaimo] Separated informative and normative text, make sure all required behaviors in normative language.
>
> - The term "The S2L Sub LSP Protection" is first in the procedures section.  It's definition / introduction is needed somewhere, either by reference or earlier in the document.  Consider if you even need to introduce this new term.
> [Huaimo] Introduced "S2L Sub LSP Protection". 
>
> - Section 6.3 seems like it's going to be an informative section, but then conformance language shows up.  I suspect the conformance language belongs in Section 5.
> [Huaimo] Removed the conformance language in this section.
>
> - Section 7 is pretty light, I suspect you can find more to say on this topic.
> [Huaimo] Added more on this topic.
>
> - The iana section doesn't follow rfc5226.  See some recent RFCs for examples. (I just reviewed draft-ietf-teas-rsvp-te-li-lb and it provides an example for exiting registries, but not establishing a new one. 
> [Huaimo] Re-wrote IANA section.
>
> - Your references need to be revisited/cleaned up.  There are some clearly stale references and the normative/informative split doesn't make a whole lot of sense.
> [Huaimo] Cleaned up the references.
>
> That's what I see based on a quick skim. 
>
> Also, when do you expect to upload draft-ietf-teas-rsvp-ingress-protection?
> [Huaimo] draft-ietf-teas-rsvp-ingress-protection is uploaded. It is ready for WGLC.
>
> Happy new year to you as well.
>
> Lou