Subject: [CCAMP] I-D Action: draft-ietf-ccamp-lsp-diversity-05.txt

From: [email-masked]
Date: Mon, 27 Oct 2014 11:55:15 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

        Title           : Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route
        Authors         : Zafar Ali
                          George Swallow
                          Fatai Zhang
                          Dieter Beller
	Filename        : draft-ietf-ccamp-lsp-diversity-05.txt
	Pages           : 27
	Date            : 2014-10-27

Abstract:
   RFC 4874 specifies methods by which path exclusions can be
   communicated during RSVP-TE signaling in networks where precise
   explicit paths are not computed by the LSP source node. This
   document specifies procedures for additional route exclusion
   subobject based on Paths currently existing or expected to exist
   within the network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-lsp-diversity-05

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: Dhruv Dhody <[email-masked]>
Date: Fri, 31 Oct 2014 13:02:38 +0530

Hi Editors,

Thanks for your work in this draft, here are a few comments -

- sec 1.2
OLD:
      With this additional information, the source is able to signal
      the subsequent LSPs with the ERO set to {C, D, exclude Path
      Key(EXRS), loose Dst}. When the signaling message reaches node X,
      it can consult node U to expand the Path Key and know how to
      avoid the path of the first LSP.
NEW:
      With this additional information, the source is able to signal
      the subsequent LSPs with the ERO set to {C, D, X, exclude Path
      Key(EXRS), loose Dst}. When the signaling message reaches node X,
      it can consult node U to expand the Path Key and know how to
      avoid the path of the first LSP.

In this case, it is up to the node X to expand the path-key.

OLD:
      This mechanism can work with all the Path-Key resolution
      mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co-
      located or not, may be used to resolve the Path-Key, but the node
      (i.e., a Label Switching Router (LSR)) can also use the Path Key
      information to index a Path Segment previously supplied to it by
      the entity that originated the Path-Key, for example the LSR that
      inserted the Path-Key in the RRO or a management system.
NEW:
      This mechanism can work with all the Path-Key resolution
      mechanisms, as detailed in section 3.1 of [RFC5553] including -
      o co- located PCE
      o an external PCE used to resolve the Path-Key
      o the node (i.e., a Label Switching Router (LSR)) using the
         Path Key information to index a Path Segment previously
         supplied to it by the entity that originated the Path-Key (for
         example the LSR that inserted the Path-Key in the RRO)
       o a management system

To improve the readability!

- sec 1.3

How is PAS related to Macro-SRLG
[http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-07#section-5.3.3.1]?
At the end both are aiming to abstract the SRLG information.

Can the network-assigned identifier also used for link or
node-disjoint (using E-flags)?
The current text only mention SRLG in description.

- sec 2.1.1

The A-flags and E-flags should be specified by bit numbers rather 0x01, 0x02...

Editorial Nits
- Follow the latest RFC style guide [http://www.rfc-editor.org/styleguide.html]
- Expand LSP, RSVP-TE on first use
- sec 1 s/EN2 to EN3 going via CN4/EN2 to EN3 traversing CN4
- sec 1.2
OLD:
      The Path Key Subobject assigns an
      "identifier" to the key.
NEW:
      The Path Key Subobject uses the Path key as
      an identifier.
s/Figure 1: A Simple Multi-Domain Network/Figure 2: A Simple
Multi-Domain Network

- we used following terms
   ~ identifier allocated by the (core) network
   ~ CN ingress node (UNI-N) allocated Identifier
   ~ Network-Assigned Identifier
   ~ Path Affinity Set (PAS) identifier
   we can benefit from a single term for readability in the document.

Regards,
Dhruv

On Tue, Oct 28, 2014 at 12:25 AM,  <[email-masked]> wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp