two small points, RE: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>    it is technically feasible that the
>>    existing MPLS architecture can be extended to meet the requirements
>>    of a Transport profile, and that the architecture allows for a single
>>    OAM technology for LSPs, PWs, and a deeply nested network.
>
> The "OAM technology" in this text refers to to way the OAM frames can be
> detected in a data-stream.

During the JWT effort, I did not interpret the term "OAM technology" to be strictly limited to just the manner in which OAM frames are detected in the data-stream. I interpreted this in a broader sense. 

> Looking at the current discussions, there is no consensus (yet)
> on whether we need a comprehensive set of OAM tools, or a very
> limited set of OAM tools. 

I don't understand this comment. We have requirements documents that have been agreed and published, and that carefully lay out a list of capabilities that need to be available. We need tools that fulfill these requirements. Perhaps I am not sure what distinction you make between "comprehensive set of OAM tools" versus "limited set of OAM tools".

Ross
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]