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

[Dhruv Dhody <[e-mail]>]

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,  <[e-mail]> wrote:
>
> 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/
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp