[CCAMP] Some comments on mpls-tp-rsvpte-ext-associated-lsp

[Lou Berger <[e-mail]>]

Authors,
	Good progress on the draft so far.  In looking at the previous mail, I
noticed a few things in the draft that I think could improve the clarity
of the draft.  Note that a bunch of these comments are style in nature,
not technical.  Also comments are made as a WG contributor, not chair.

Some general comments:
- There is no/little conformance language related to the Single Sided
Provisioning.  This is a huge hole in the draft.

- As mentioned in my previous mail, backwards compatibility needs to be
address

- How are you thinking about providing the ERO (and perhaps RRO?) for
the reverse LSP when using Single Sided Provisioning?  (Keep in mind we
already have EROs/RROs and SEROs/SRROs, it would be good to figure out
if these can be leveraged.)

- How does 4872/3 style recovery work for the reverse LSP?

- You introduce the new, and somewhat confusing, term: "Two Reverse
Unidirectional LSPs".  TP already has a term for this, i.e.,
"Associated Bidirectional LSPs".  I think the document should just use
this established term.

For the following I'm using line numbers found via
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01.txt

Line 1: The document is in ccamp not mpls.

Line 8: "Establish Associated Bidirectional LSP".  Presumably, this also
will cover more than just establishment, so perhaps replace "to
Establish" with "For" and "LSP" with "LSPs".

Lines 132/134:  The section is titled association .. of LSPs, but the
first topic is provision models and it certainly covers more than
association.  Perhaps the title should be something more general, even
"Associated Bidirectional LSPs", or "Overview".

Section 3.  As this section is a narrative, the very few instances of
RFC2119 language seems out of place, i.e., belongs in section 4 and 5
and should be moved or removed.

Section 3.2.2.  I think this is really overly complex and likely to lead
to the same issues and confusion we've seen in e2e recovery.  Is there
any reason not to keep it simple and say something along the lines of
"the values used in the ASSOCIATION object are outside the scope of this
document.  For example they may be communicated via the management
plane. No matter how the values are communicate, identification of the
LSPs as being Associated Bidirectional LSPs occurs based on the
identical contents in the LSPs' ASSOCIATION objects"

Section 3.3: doesn't cover recovery of LSP2.

Line 437: Suggest renaming to "Association of LSPs".

Section 4: I think this is where any discussion of Association object
modifications, procedures, and conformance language should be consolidated.

Lines 443-529: In general, one document should not repeat the format
from another for informational purposes, so most of these lines should
be dropped.  All you need is a statement to the affect that the Extended
ASSOCIATION object is defined in [I-D.ietf-ccamp-assoc-ext] MUST be used.

Line 496:  Should use the standard term "Associated Bidirectional LSPs".

Lines 498-500: This sentence relates to nodes that do *not* implement
this draft, as such is way outside the scope of the document and must be
removed.

Lines 507-509, 523-529: In general I think it is a mistake to proscribe
use of LSP or tunnel IDs as association IDs.  Using the assoc-ext rules,
it isn't an interoperability concern, and such usage leads to the
confusion/issues covered in the assoc-info draft.  I think the 4872
definition is sufficient for Association ID and assoc-ext is sufficient
for Extended Association ID.

Section 5:  Suggest renaming "Single Sided Provisioning" and including
all the related modifications, procedures, and conformance language in
this section.
Topics to be covered include, in no particular order:
- LSP Control (Establishment, teardown, modification including MBB.
Don't forget about the attributes and admin status objects -- maybe
there's a generic approach that can be followed, e.g., a REVERSE_LSP
object that carries objects for use by the reverse LSP

- Symmetric and Asymmetric BW (If not covered under a generic approach)
Explicit control of the reverse LSP (If not covered under a generic
approach)
- Record route of the reverse LSP (If not covered under a generic approach)
- Recovery (If not covered under a generic approach)
- Compatibility
- Updated RSVP Message Formats (as needed)

Lou