Re: [mpls] Comments on draft-ietf-mpls-tp-cc-cv-rdi-01

[David Allan I <[e-mail]>]

Hi Greg:

Thanks for the read of the document and the feedback....



Dear Authors and All,
please find my comments to the document below:

*         Abstract, first paragraph s/are/the

OK

*         Section 3. From description of CV mode it is not clear, as from description of CC mode, whether RDI functionalities supported in CV mode. Though description of RDI explicitly mentions that. Either mention RDI functionality in connection to CV mode or remove it from CC for consistency.

We will clarify in the next version.

*         Section 3.1 "It's possible to run BFD in CC mode on some transport paths and BFD in CV mode on other transport paths." I think that this is important to mention only for paths between the same pair of end nodes.

It would be even clearer if the mode was MEG specific. MEs in a MEG need to be homogenous in operation. If you agree we'll edit accordingly.

*         Section 3.4 "A BFD session is enabled when the CC or proactive CV functionality is enabled on a configured Maintenance Entity (ME) or in the case of an associated bi-directional path, pair of Maintenance Entities" conflicts with "A new BFD session is initiated when the operator enables or re-enables the CC or CV functionality on the same ME" as the latter statement refers to a single ME instance regardless whether bi-directional path is co-routed or associated. I think that a BFD session is one-to-one mapped with ME regardless number of MEs that used to monitor connectivity and/or continuity of p2p bidirectional path.

This has come up before, I believe the correct resolution is an associated bi-directional path is a single ME. We will edit accordingly.

*         Section 3.5, first paragraph. I think that even though BFD is capable to change frequency of transmitting messages on a fly, in MPLS-TP such action must go through Admin Down state as one BFD session is effectively taken down and another, with different parameters, is enabled.

I agree we do not want any changes on the fly. And we could say MUST for admin down to change anything, but that also means there are likely existing implementations out there that may not respect this.

*         Section 3.5,  p.7. I think that there's another clarification of how MEP with zero transmit rate send its BFD control packets will be in useful - how this MEP sends these packets. Perhaps use of ACH encapsulation over reverse direction of the associated bi-directional path will be default behavior. But it could be over DCN with or without IP addressing.

I'll take a look and see if this should be clarified.

cheers

Dave