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

From: [email-masked]
Date: Mon, 09 Mar 2015 13:12:46 -0700

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 Ingress Local Protection
        Authors         : Huaimo Chen
                          Raveendra Torvi
	Filename        : draft-ietf-teas-rsvp-ingress-protection-02.txt
	Pages           : 23
	Date            : 2015-03-09

Abstract:
   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for locally protecting the ingress node
   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-ingress-protection/

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

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

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: Fri, 13 Mar 2015 22:34:42 +0000

Hi Everyone,

    We addressed the comments from Lou in this version.

    There are two methods for a backup ingress to get the information to provide protection for the primary ingress of an LSP in the draft. One method needs to be selected. After this is resolved, the draft is ready for WGLC.

Best Regards,
Huaimo

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 09, 2015 4:13 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt

Abstract:

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.

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Lou Berger <[email-masked]>
Date: Wed, 18 Mar 2015 08:38:58 -0400

Huaimo, Co-authors,
    What is your plan for resolving the major open issue on this
document?  (BTW I'm completely baffled by the WGLC reference!)

Also, a general comment: When addressing comments sent to the list,
please  respond directly to the message containing the comment and
discuss the details of how you (plan to) address the comment. 
Alternatively, you can summarize the details of each issue resolution in
a single message after publication of a new version.  In other words "We
addressed the comments from..." is a bit too terse.

Thanks,
Lou

On 3/13/2015 6:34 PM, Huaimo Chen wrote:
>     There are two methods for a backup ingress to get the information
> to provide protection for the primary ingress of an LSP in the draft.
> One method needs to be selected. After this is resolved, the draft is
> ready for WGLC.
>  
> Best Regards,
> Huaimo
>  
> 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.
>  
> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 20 Mar 2015 01:04:58 +0000

Hi Lou,

    Thanks much for your comments.

    For the open issue in this draft, we are going to have some meetings recently to try to resolve it.

    For your comments for the egress protection draft, which are applicable to this draft, they were addressed in the draft as follows:

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

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

> - 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] Wrote IANA section in details.

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

Best Regards,
Huaimo
-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, March 18, 2015 8:39 AM
To: Huaimo Chen; [email-masked]; [email-masked]
Cc: Raveendra Torvi; Markus Jork; [email-masked]; Richard Li; [email-masked]; Autumn Liu; Quintin zhao; Tarek Saad; Alia Atlas; Yimin Shen; Fengman Xu; [email-masked]; Lizhenbin
Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt

Huaimo, Co-authors,
    What is your plan for resolving the major open issue on this document?  (BTW I'm completely baffled by the WGLC reference!)

Also, a general comment: When addressing comments sent to the list, please  respond directly to the message containing the comment and discuss the details of how you (plan to) address the comment. 
Alternatively, you can summarize the details of each issue resolution in a single message after publication of a new version.  In other words "We addressed the comments from..." is a bit too terse.

Thanks,
Lou

On 3/13/2015 6:34 PM, Huaimo Chen wrote:
> Subject: [Teas] I-D Action: 
> draft-ietf-teas-rsvp-ingress-protection-02.txt
>  
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Mar 2015 22:22:54 -0400

>     recently to try to resolve it.

Keep in mind that any resolution must be agreed to by the WG...

Lou

>     For your comments for the egress protection draft, which are applicable to 
>     this draft, they were addressed in the draft as follows:
>
> > - 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.
>
> > - 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.
> >
>
> > - 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.
> >
>
> Cc: Raveendra Torvi; Markus Jork; [email-masked]; Richard Li; 
> [email-masked]; Autumn Liu; Quintin zhao; Tarek Saad; Alia Atlas; Yimin 
> Shen; Fengman Xu; [email-masked]; Lizhenbin
>     What is your plan for resolving the major open issue on this document?  
>     (BTW I'm completely baffled by the WGLC reference!)
>
> Also, a general comment: When addressing comments sent to the list, please  
> respond directly to the message containing the comment and discuss the 
> details of how you (plan to) address the comment.
> Alternatively, you can summarize the details of each issue resolution in a 
> single message after publication of a new version.  In other words "We