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

[[e-mail]]

Dear Lou, all

According to the comments received, we have uploaded the new version, 
below is the link：

http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02.

And the responses in details are marked as <Fei> in the initial mail for 
quick check .  O(∩_∩)O

Any more comments are welcome

Best regards

Fei



Lou Berger <[e-mail]> 
发件人:  [e-mail]
2011-08-11 22:05

收件人
[e-mail]
抄送
CCAMP <[e-mail]>
主题
[CCAMP] Some comments on mpls-tp-rsvpte-ext-associated-lsp






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.

<Fei>Section 5, the first paragraph

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

<Fei> Section 5.4

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

<Fei> Section 5.1

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

<Fei> the usage of RFC4872/3 is unchanged, section 3.2.4

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

<Fei> Accepted

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.

<Fei>Accepted

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

<Fei>Accepted

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

<Fei>Accepted

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.

<Fei>Accepted

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"


<Fei>Accepted, see section 3.2.2


Section 3.3: doesn't cover recovery of LSP2.

<Fei>Unchanged, see section 3.2.2

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

<Fei>Accepted

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

<Fei>Accepted, see section 4

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.

<Fei>Accepted, see section 4

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

<Fei>Accepted

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.


<Fei>Accepted

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.


<Fei>Accepted, see section 4


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

<Fei>See section 5.2

- Symmetric and Asymmetric BW (If not covered under a generic approach)
Explicit control of the reverse LSP (If not covered under a generic
approach)

<Fei>See section 3.2.3

- Record route of the reverse LSP (If not covered under a generic 
approach)

<Fei> Not addressed now, I do not catch the idea clearly 

- Recovery (If not covered under a generic approach)

<Fei>See section 3.2.4

- Compatibility

<Fei>See section 5.4

- Updated RSVP Message Formats (as needed)

<Fei>See section 5.3

Lou
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp