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

[[e-mail]]

Hi Lou

Thanks for so many valuable comments

Please see in line with <Fei>

B.R.

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> Do you mean to add them in section 5?

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

<Fei> Will be added in section 5

- 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> Actually I think ERO wil be useful.
 Consider that one PCE is used to calcualate the TE-LSPs, it will give 
both directional's informations to 
the ingress LSR. The reverse LSP's path will be carried in the forward 
LSP's PATH message.

For the RRO function, if the egress LSP wants to get the information of 
the forward LSP, it just needs to check the forward LSP's PATH message.
I do not see any reason to carry it, can you clarify on this point?

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

<Fei> I have not thought about this before, this will be a bit more 
complicated, but your suggestion to define a new top level object will be 
helpful.

- 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> Will correct

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> Sorry for the error, will correct

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

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

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> will correct

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> No specially reason, will revise it.

Section 3.3: doesn't cover recovery of LSP2.

<Fei> The recovery of LSPs follows the same way as LSP1. The description
      will be added

Line 437: Suggest renaming to "Association of LSPs".
<Fei> OK.

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.

<Fei> OK

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

<Fei> OK

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

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> The e2e recovery association [RFC4872] was based on the LSP ID, for 
the
Work and protection LSPs are in the same tunnel; 
RFC4873 did not give this restriction, just based on the unique value.
I think you mean RFC4873 definition is sufficient?

Yeah, this will take the interoperability concern. 
My initial idea is that TP-identifier(including global ID_node ID_tunnel 
ID_LSP ID)
gives the unique value that match the association> Since global ID and 
node ID has been
defined in the Extended association object, Tunnel ID+ LSP ID will be 
gloabal unique, and
it is just a kind of association ID.

I agree with you that the unique value is not needed to be the LSP ID+ 
Tunnel ID, will
relax the limitation.

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)

<Fei>We will give a updated version to cover these content

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